curl không đọc được tệp PAC của bạn: hãy truyền proxy thay vào

Địa chỉ tệp PAC và điểm cuối của proxy trông như thể hoán đổi được cho nhau trong tệp cấu hình, nhưng không phải vậy. Một cái là chương trình chính sách phải được đánh giá cho từng URL; cái kia là một máy chủ và cổng tiếp nhận kết nối. curl chỉ hiểu cái thứ hai. Truyền một địa chỉ PAC cho --proxy là lỗi phân loại, thất bại theo cách khó hiểu, thường sau một thời gian chờ CONNECT dài tới máy chủ web.

Mỗi thứ thực sự là gì

Điều này được nói rõ trong câu hỏi thường gặp về curl: curl không cung cấp bất kỳ cách diễn giải JavaScript hay PAC nào. Một lớp bọc quanh curl hiểu PAC thì có thể, nhưng bản thân curl thì không, và không cờ nào biến nó thành trình duyệt.

Vì sao trình duyệt làm được còn curl thì không

Trình duyệt tích hợp với cấu hình proxy của hệ thống, tải tệp PAC và chạy các quy tắc của nó đối với URL bạn mở. Việc đánh giá đó chính là dịch vụ mà tệp PAC cung cấp, và nó diễn ra bên trong trình duyệt, không phải trong terminal của bạn.

Tải tệp PAC bằng curl chỉ lấy được văn bản của nó. Nó không khiến curl thực thi chính sách, và đọc thủ công để tìm proxy là phiên bản thủ công của cùng phép đánh giá đó, với cùng khả năng chọn nhầm nhánh. Nếu bạn đọc nó, hãy đọc câu lệnh return khớp với máy chủ của bạn thay vì tên proxy đầu tiên trong tệp. Hầu hết tệp PAC chứa vài cái, và chỉ một nhánh áp dụng cho bạn.

Với một proxy HTTP đã được phê duyệt và một dịch vụ HTTPS đã được phê duyệt, một yêu cầu minh họa là:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Địa chỉ đầu tiên là trình lắng nghe của proxy, địa chỉ thứ hai là dịch vụ bạn muốn. Đây là các điểm cuối ví dụ chứ không phải một bài kiểm tra ai đó đã thực hiện, nên hãy thay bằng lược đồ, cổng và quy trình xác thực của tổ chức bạn.

Chọn proxy cho đích đến này

Hỏi quản trị viên xem chính sách chọn proxy nào cho URL bạn cần, chứ không phải tổ chức sở hữu proxy nào. Các quy tắc PAC có thể trả về kết quả khác nhau cho dịch vụ nội bộ, trang công khai và tình huống chuyển đổi khi có sự cố, và một quy tắc khớp với URL của bạn hôm nay có thể khớp với URL khác sau khi chỉnh sửa.

Nếu quy trình làm việc cần nhiều hơn một yêu cầu đã biết, hãy dùng một thiết lập tĩnh được quản trị viên hỗ trợ hoặc một tích hợp hiểu PAC đã được phê duyệt. Mã hóa cứng một địa chỉ đã sao chép chỉ dùng được đến ngày chính sách thay đổi và không ai còn nhớ vì sao địa chỉ đó được chọn.

Sau đó xem curl thừa hưởng những gì. Các biến môi trường proxy và NO_PROXY có thể ghi đè hoặc loại trừ proxy bạn đã truyền, và một loại trừ khớp với đích của bạn sẽ âm thầm gửi yêu cầu trực tiếp. Hãy giữ chính sách dự định thay vì xóa mọi loại trừ hoặc ép mọi thứ đi qua một địa chỉ. Chạy yêu cầu một lần với -v và kiểm tra xem nó thực sự kết nối tới địa chỉ nào.

Giữ hai danh tính TLS tách biệt

Với proxy HTTPS, có hai kết nối TLS tham gia: của bạn tới proxy và của proxy tới đích. Mỗi kết nối có danh tính riêng để xác minh, và tắt xác minh cho bất kỳ kết nối nào không phải là sửa PAC, mà là vấn đề thứ hai thêm vào vấn đề đầu tiên.

Hãy để xác minh bật và đọc lỗi bạn nhận được. Thử thách xác thực proxy, proxy không thể tới được và sự từ chối từ trang web là ba kết quả khác nhau, và chỉ kết quả đầu liên quan tới thông tin đăng nhập. VPN vẫn phải cung cấp một đường đi được phép tới proxy riêng, bao gồm phân giải tên cho chính máy chủ proxy, trước khi bất kỳ điều nào trong số này thành công.

Ghi lại điểm cuối, lược đồ, cổng, phương thức xác thực, các loại trừ và đường VPN tới proxy. Chính bản ghi đó khiến yêu cầu tiếp theo có thể tái lập, và đó là khác biệt giữa hiểu rõ proxy của bạn và đoán mò về nó.