Mở phần cài đặt mạng trên điện thoại hoặc laptop, bạn có thể sẽ thấy mục HTTP Proxy với các lựa chọn như Tắt, Thủ công và Tự động. Quy tắc an toàn rất đơn giản: nếu không có quản trị viên đáng tin cậy hoặc ứng dụng cụ thể nào cung cấp thông tin proxy cho bạn, đừng tự đoán. Địa chỉ proxy không phải công tắc tăng tốc hay chế độ ẩn danh. Nó chỉ thay đổi nơi các yêu cầu HTTP của bạn được gửi đến.
Một ô cài đặt nhỏ như vậy lại che giấu cả một chủ đề rất rộng. HTTP proxy có thể thực thi chính sách của công ty, định tuyến các lệnh gọi API của lập trình viên, lưu cache phản hồi dùng chung, hoặc tạo đường hầm cho HTTPS. Reverse proxy cũng có thể đứng ở phía bên kia của luồng trao đổi, phía trước website thay vì phía trước người dùng. Nhưng không có vai trò nào trong số đó tự động khiến kết nối trở nên riêng tư, ẩn danh, nhanh hơn hay được cấp quyền.
Hướng dẫn này sẽ giải thích theo đúng giao thức chứ không theo nhãn tiếp thị: HTTP proxy là gì, dữ liệu thực sự đi qua đường dây ra sao, CONNECT khác gì với chuyển tiếp thông thường, SOCKS5 và VPN nằm ở đâu, và cách gỡ lỗi proxy mà không phải thay bừa năm cài đặt cùng lúc.
HTTP Proxy là gì?
HTTP proxy là một trung gian nhận yêu cầu HTTP và cố gắng đáp ứng yêu cầu đó bằng cách chuyển tiếp, trả về phản hồi đã lưu khi được phép, hoặc tự tạo phản hồi của riêng nó. RFC 9110 gọi proxy do client chọn là một tác nhân chuyển tiếp thông điệp. Thông thường, client sẽ biết đến nó từ cài đặt ứng dụng, cài đặt hệ điều hành, tệp Proxy Auto-Configuration (PAC), hoặc biến môi trường.
Với forward proxy tường minh, luồng sẽ như sau:
client ---> forward proxy ---> origin server
<--- <---
Client kết nối đến proxy trước. Sau đó proxy mới mở hoặc tái sử dụng kết nối đến đích. Origin thường sẽ nhìn thấy kết nối mạng của proxy như là đối tác trực tiếp, nhưng điều đó không đồng nghĩa với ẩn danh. Header, cookie, dấu vân tay trình duyệt, phiên đăng nhập, hành vi DNS và nhật ký hệ thống vẫn có thể xác định người dùng hoặc tổ chức. “Origin thấy IP nguồn khác” và “người dùng ẩn danh” là hai khẳng định hoàn toàn khác nhau.
HTTP proxy cũng không phải là mã hóa. HTTP thường vẫn là HTTP thuần nếu không có lớp bảo mật khác bảo vệ. HTTPS có thể đi qua proxy dưới dạng một đường hầm TLS, nhưng phần mã hóa đến từ TLS chứ không phải từ chữ proxy.
HTTP Proxy tường minh xử lý một yêu cầu như thế nào
Khác biệt quan trọng nằm ở mục tiêu của request. Khi một client HTTP/1.1 nói chuyện trực tiếp với origin server, nó thường gửi origin-form:
GET /reports/weekly HTTP/1.1
Host: example.com
Khi cùng client đó gửi một yêu cầu HTTP thông thường tới một proxy tường minh, RFC 9112 quy định absolute-form để proxy nhận biết đích đến:
GET http://example.com/reports/weekly HTTP/1.1
Host: example.com
Quy trình điển hình là:
- Client chọn proxy theo các quy tắc cấu hình đang áp dụng.
- Client kết nối đến proxy và gửi yêu cầu có chứa URI đích.
- Proxy có thể xác thực client, áp chính sách, tra cache, hoặc từ chối yêu cầu.
- Nếu được phép chuyển tiếp, proxy sẽ gửi yêu cầu phù hợp đến origin.
- Phản hồi quay trở lại qua proxy. Proxy có thể thêm metadata trung gian, biến đổi thông điệp khi được phép, lưu phản hồi có thể cache, hoặc chỉ đơn giản là chuyển tiếp nguyên trạng.
Từ “có thể” ở trên là rất quan trọng. HTTP chỉ định các hành vi và quy tắc tương thích có thể xảy ra; nó không đảm bảo mọi proxy đều lọc nội dung, cache phản hồi, viết lại header, hay ẩn định danh.
Nếu proxy yêu cầu xác thực, nó có thể trả về 407 Proxy Authentication Required. Điều này khác với 401 Unauthorized: 407 liên quan đến thông tin đăng nhập cho proxy, còn 401 liên quan đến origin server. RFC 9110 định nghĩa rõ sự khác biệt này. Thông tin xác thực cũng cần đi qua một kênh được bảo vệ phù hợp; Basic authentication tự nó không tạo ra tính bảo mật.
HTTPS đi qua HTTP Proxy: CONNECT là đường hầm, không phải mã hóa
Với đích HTTPS, client thường yêu cầu proxy mở một TCP tunnel bằng CONNECT. Phần đích của request dùng authority-form — host cộng port — chứ không phải toàn bộ URL:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Sau khi nhận phản hồi thành công, kết nối trở thành một đường hầm. Lúc này client sẽ thực hiện bắt tay TLS với example.com thông qua luồng byte đó:
client == TLS ==[ proxy relays bytes ]== TLS endpoint at origin
Trong mô hình tunneling thông thường này, proxy có thể nhìn thấy metadata của kết nối như proxy user, authority đích, thời gian và số byte, nhưng nội dung request và response HTTPS vẫn được mã hóa bằng TLS. Bản thân đường hầm không phải là cơ chế mã hóa. Phân biệt này rất quan trọng khi chẩn đoán lỗi: CONNECT có thể thành công nhưng bước TLS handshake sau đó lại thất bại.
Một số mạng được quản lý sẽ thực hiện chặn TLS có cấp phép. Trong thiết kế đó, trung gian chấm dứt một kết nối TLS và tạo một kết nối khác đến origin. Client phải tin cậy một certificate authority được dùng bởi hệ thống triển khai đó. Khi đó trung gian có thể kiểm tra nội dung HTTP vì nó là một endpoint TLS, chứ không phải vì mọi HTTP proxy đều có thể “đọc” HTTPS bằng phép màu. Đây phải là một chính sách được quản trị rõ ràng trên thiết bị được quản lý. Tắt kiểm tra chứng chỉ không phải là cách khắc phục hợp lệ trong môi trường production khi gặp lỗi chứng chỉ bất ngờ.
Bên phía proxy cũng có ranh giới bảo mật. Cho phép CONNECT đến bất kỳ host và port nào có thể biến proxy thành một con đường dẫn đến những dịch vụ vốn không nên bị lộ. Proxy production nên giới hạn đích đến và cổng theo đúng mục đích sử dụng.
Forward, Reverse, Explicit và Interception Proxy
Tên gọi proxy dễ gây rối khi hai trục khác nhau bị gộp vào một danh sách.
Trục thứ nhất là ai chọn trung gian:
- Forward proxy được chọn thay cho client. Nó kiểm soát hoặc hỗ trợ truy cập outbound từ client hoặc mạng đó.
- Reverse proxy, trong ngữ nghĩa HTTP còn gọi là gateway, nằm phía trước một hoặc nhiều origin server. Người truy cập gọi đến dịch vụ công khai; gateway sẽ chọn backend, chấm dứt TLS, cache phản hồi đủ điều kiện hoặc áp chính sách phía server.
Trục thứ hai là traffic đi đến trung gian bằng cách nào:
- Explicit proxy đã được biết trước trong cấu hình của client. Client chủ động định dạng request cho nó hoặc mở đường hầm
CONNECT. - Interception proxy nhận traffic được mạng chuyển hướng, không cần cấu hình proxy tường minh bình thường ở phía client.
Các nhãn này có thể chồng lên nhau. Một forward proxy trong doanh nghiệp có thể là explicit. Một network gateway có thể chặn và nhận một phần traffic outbound. Reverse proxy thường vô hình với visitor như một chặng riêng, dù nó vẫn là server mà client kết nối đến.
Interception không chỉ đơn giản là “proxy tường minh nhưng không có màn hình cài đặt”. Nó có thể làm xáo trộn các giả định về địa chỉ đích, xác thực, TLS và path MTU. Hướng dẫn về interception của Squid ghi nhận nhiều ràng buộc vận hành như vậy. Nếu mạng không đáp ứng được chúng, kết quả thường là lỗi cục bộ rất khó hiểu thay vì một thông báo rõ ràng (kiểu lỗi mà ai cũng ghét nhất).
Các thuật ngữ như anonymous, elite, và high-anonymity chủ yếu thuộc về phân loại của nhà cung cấp. Chúng không phải là khả năng chính thức của HTTP. Hãy đánh giá hành vi có thể quan sát được mà bạn cần — header, địa chỉ egress, xác thực, logging, phân giải DNS và chính sách tunnel — thay vì xem một nhãn như cam kết bảo mật.
HTTP Proxy vs. SOCKS5 vs. VPN
Không có thứ hạng phổ quát nào đáng tin cậy để nói rằng một trong ba luôn nhanh hơn, rẻ hơn hay riêng tư hơn. Hiệu năng phụ thuộc vào khoảng cách, nghẽn mạng, mã hóa, cách triển khai, giao thức và đích đến. Chi phí phụ thuộc vào nhà cung cấp và cách triển khai. Hãy so sánh theo ranh giới kiểm soát.
| Câu hỏi | HTTP proxy | SOCKS5 proxy | VPN |
|---|---|---|---|
| Client dùng giao diện nào? | Chuyển tiếp HTTP và thường là tunnel CONNECT | Các lệnh của giao thức SOCKS | Một đường hầm mạng/ảo do hệ điều hành hoặc VPN client quản lý |
| Loại traffic nào được dùng? | Traffic từ các ứng dụng hỗ trợ HTTP proxy đã cấu hình | TCP, và cả UDP association khi client và server hỗ trợ | Traffic được chọn theo routing và chính sách split-tunnel |
| Cơ chế này có đảm bảo mã hóa payload không? | Không | Không | Tunnel VPN thường bảo vệ traffic bên trong ranh giới đã cấu hình; giao thức và chính sách vẫn rất quan trọng |
| Thường cấu hình ở đâu? | Ứng dụng, hệ điều hành, PAC/WPAD, hoặc biến môi trường | Từng ứng dụng hoặc thư viện | Hệ điều hành hoặc VPN client, đôi khi theo từng app |
| Ai phân giải DNS đích? | Tùy client, chế độ request và cách triển khai | Tùy cách client cung cấp đích đến | Tùy routing của VPN và chính sách DNS |
| Câu hỏi quyết định tốt nhất | Ứng dụng hỗ trợ HTTP này có cần một trung gian không? | Ứng dụng này có cần một giao diện relay tổng quát hơn không? | Những route nào của thiết bị hoặc ứng dụng nên đi vào một tunnel mạng được mã hóa? |
SOCKS5 định nghĩa CONNECT, BIND và UDP ASSOCIATE. Điều đó khiến nó tổng quát hơn so với chuyển tiếp chỉ dành cho HTTP, nhưng vẫn không hứa hẹn mã hóa hay ẩn danh. Bảo mật phụ thuộc vào xác thực, kênh bảo vệ bên ngoài nếu có, hành vi của endpoint và người vận hành.
VPN thường hoạt động ở một ranh giới mạng rộng hơn, nhưng nói rằng “VPN luôn mang mọi byte từ thiết bị” là sai. Split tunneling có thể bao gồm hoặc loại trừ một số route hay app nhất định. Tài liệu triển khai VPN của Apple là một ví dụ về nền tảng hỗ trợ hành vi VPN có phạm vi giới hạn.
Hãy chọn theo phạm vi và mức độ tin cậy, không chọn theo nhãn một từ. Nếu chỉ một ứng dụng HTTP cần đi qua cổng công ty, thì VPN toàn thiết bị có thể là không cần thiết. Nếu nhiều ứng dụng cần truy cập mạng nội bộ, việc cấu hình nhiều HTTP proxy riêng lẻ có thể là một cách tiếp cận không đúng bản chất.
Nên bật hay tắt cài đặt HTTP Proxy?
Với mạng gia đình không được quản lý, hãy để tắt trừ khi một dịch vụ đáng tin cậy mà bạn chủ động sử dụng cung cấp sẵn địa chỉ, cổng và phương thức xác thực. Bật một proxy công khai ngẫu nhiên nghĩa là bạn đang gửi traffic đến một nhà vận hành mà bạn chưa kiểm tra.
Với thiết bị công việc hoặc trường học được quản lý, hãy làm theo hướng dẫn hiện tại của quản trị viên. Đừng gỡ một cấu hình lạ trước khi kiểm tra xem đó có phải là do hệ thống quản lý thiết bị, VPN/security client hay quản trị viên thiết lập hay không. Proxy có thể là một phần của kiểm soát truy cập; xóa nó đi có thể làm hỏng quyền truy cập hoặc vi phạm chính sách, dù sau đó việc duyệt web thông thường có vẻ vẫn hoạt động.
“Tự động” thường là nói đến URL PAC hoặc một cơ chế tự phát hiện. Một PAC file là JavaScript có thể trả về route khác nhau cho từng URL — ví dụ, gửi một hostname nội bộ qua proxy trong khi kết nối trực tiếp đến một site công khai. Điều đó có nghĩa là trình duyệt có thể hoạt động với một đích nhưng lại lỗi với đích khác dù nhìn bề ngoài cùng một cài đặt.
Menu cụ thể sẽ thay đổi theo từng phiên bản, vì vậy hãy dùng tài liệu mới nhất của nhà cung cấp thay vì ảnh chụp màn hình trong bài viết cũ. Những câu hỏi bền vững cần quan tâm là:
- Cài đặt này do tổ chức quản lý hay do người dùng nhập vào?
- Nó là Manual, PAC/Auto hay theo từng ứng dụng?
- Nó bao phủ những giao thức và đích đến nào?
- Có quy tắc bỏ qua nào như
NO_PROXYhoặc “exclude simple hostnames” không? - Khi app, hệ điều hành, environment và PAC không đồng ý với nhau thì cấu hình nào thắng?
Câu hỏi cuối cùng đó phụ thuộc vào từng client. Chrome/Chromium thường tích hợp với cách phân giải proxy của nền tảng nhưng cũng có bộ quy tắc riêng đã được tài liệu hóa. Firefox có thể dùng cài đặt kết nối của riêng nó. Các công cụ dòng lệnh thường đọc biến môi trường độc lập. Vì vậy, proxy hệ thống đã được cấu hình không có nghĩa là mọi ứng dụng đều dùng nó.
Dùng HTTP Proxy trong curl và Python
Với một request một lần, tùy chọn --proxy của curl giúp lựa chọn này hiển thị rõ ràng:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
'https://api.example.com/health'
Nếu cần xác thực, đừng đặt bí mật thật vào mã nguồn, lịch sử shell, ảnh chụp màn hình hay ví dụ trong bài viết. Hãy dùng cơ chế thông tin đăng nhập đã được phê duyệt cho môi trường của bạn. Ví dụ dưới đây cố tình dùng placeholder:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
--proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
'https://api.example.com/data'
Với tự động hóa dài hạn, hãy fail closed. Nếu chính sách yêu cầu request phải đi qua proxy, đừng bắt lỗi proxy rồi âm thầm thử lại trực tiếp. Một đường fallback trực tiếp có thể làm lộ địa chỉ egress của client hoặc vượt qua chính sách truy cập.
Python Requests chấp nhận một ánh xạ rõ ràng:
import os
import requests
proxy_url = os.environ["APP_PROXY_URL"]
proxies = {
"http": proxy_url,
"https": proxy_url,
}
response = requests.get(
"https://api.example.com/health",
proxies=proxies,
timeout=(5, 20),
)
response.raise_for_status()
print(response.json())
Khóa https ở trên có nghĩa là “dùng proxy này cho đích HTTPS”; nó không nhất thiết có nghĩa là client sẽ thiết lập TLS tới proxy. Một URL proxy http:// vẫn có thể nhận CONNECT và chuyển tiếp TLS đến origin. Requests cũng có tài liệu về hỗ trợ biến môi trường và xử lý CA bundle trong hướng dẫn proxy nâng cao.
Hành vi của environment không hoàn toàn đồng nhất. curl cố ý chấp nhận chữ thường http_proxy, trong khi các biến và công cụ khác có thể chấp nhận cách viết khác. Việc khớp NO_PROXY, hỗ trợ CIDR, dấu chấm đầu dòng, cổng, hành vi loopback và thứ tự ưu tiên đều có khác biệt. Hãy xem tài liệu của runtime cụ thể như hợp đồng chính thức. Đừng cho rằng một lệnh curl chạy được có nghĩa là Requests, Go, trình duyệt và container cũng sẽ chọn cùng một route.
Cũng đừng dùng “cách sửa” này:
# Không dùng cách này để che giấu lỗi chứng chỉ trong production.
requests.get("https://api.example.com", verify=False)
Nếu một proxy kiểm tra được phép dùng certificate CA riêng, hãy cài đặt hoặc tham chiếu đúng trust bundle. Nếu proxy đó không được cấp phép, hãy dừng lại và điều tra.
Gỡ lỗi HTTP Proxy theo từng lớp
Lỗi proxy sẽ dễ kiểm soát hơn khi bạn kiểm tra từng lớp một:
- Chọn cấu hình: Xác nhận ứng dụng bị lỗi thực sự đang dùng nguồn proxy nào — cài đặt thủ công, cài đặt hệ thống, PAC, biến môi trường, hay cấu hình riêng của ứng dụng. Kiểm tra cả quy tắc bỏ qua.
- Phân giải tên miền: Xác định client tự phân giải đích đến hay gửi hostname để proxy phân giải. Hãy kiểm tra riêng hostname của proxy.
- Khả năng kết nối TCP: Client có kết nối được đến host và port của proxy không? Timeout ở bước này không phải là lỗi HTTP.
- Xác thực proxy:
407nghĩa là proxy đang yêu cầu thông tin đăng nhập. Đừng nhầm nó với401từ origin. - Chuyển tiếp HTTP: Với đích HTTP thuần, hãy kiểm tra mã phản hồi và xem request có dùng absolute-form đúng không.
- Chính sách CONNECT: Với HTTPS, hãy xác minh proxy có cho phép host và port đích hay không. Một tunnel bị từ chối sẽ không bao giờ đến được giai đoạn TLS.
- TLS: Sau khi CONNECT thành công, hãy kiểm tra danh tính chứng chỉ, chuỗi tin cậy, bắt tay giao thức và việc chặn TLS có cấp phép có đúng như dự kiến không.
- Phản hồi từ origin:
403,404hoặc429từ đích không tự động là lỗi proxy — và cũng không cho phép bạn đổi danh tính hay vượt qua kiểm soát.
Một số trung gian có thể phát ra trường tùy chọn Proxy-Status với thông tin chẩn đoán. Hãy dùng khi có, nhưng đừng thiết kế toàn bộ quy trình gỡ lỗi chỉ dựa vào nó. Nhật ký từ client, proxy và origin vẫn là cách đáng tin cậy nhất để xác định chặng nào bị lỗi.
Còn proxy caching thì sao?
Shared caching rất hữu ích, nhưng đó là tính năng có điều kiện chứ không tự động. RFC 9111 yêu cầu shared cache phải xem xét method, cache key, freshness, response directives, authorization và quy tắc revalidation trước khi tái sử dụng một response.
Bốn chỉ thị thường bị hiểu sai:
privateyêu cầu shared cache không lưu response đó (hoặc các field được chỉ định).no-storeyêu cầu cache không lưu message, nhưng RFC nói rõ rằng nó không phải là cơ chế bảo mật hoàn chỉnh.no-transformyêu cầu các trung gian không biến đổi representation.proxy-revalidateảnh hưởng đến việc tái sử dụng sau khi response đã lưu trở nên stale; nó không làm cho một response vốn không thể cache trở nên cacheable.
HTTPS được tunnel end-to-end là không thể đọc được đối với forward proxy, nên proxy đó không thể đóng vai trò HTTP content cache cho các message mã hóa bên trong tunnel. Reverse proxy hoặc gateway chấm dứt TLS được phép là một kiến trúc khác.
HTTP Proxy, Web Scraping và Thunderbit
Các hệ thống thu thập dữ liệu có thể dùng proxy để kiểm soát egress, định tuyến theo khu vực, tách workload hoặc giữ một danh tính mạng ổn định. Đó là khả năng định tuyến, không phải giấy phép sử dụng. Proxy không cấp quyền thu thập một trang, không vượt qua kiểm soát truy cập, cũng không đảm bảo mục tiêu sẽ chấp nhận yêu cầu. Các mã trạng thái như 403 và 429, hoặc CAPTCHA, cần được xử lý theo chính sách chứ không phải bằng một công thức “đổi loại proxy” tự động.
Cũng còn một lựa chọn về tầng trừu tượng. Một forward proxy thô đưa cho developer một giao diện định tuyến hoặc tunnel HTTP. Ứng dụng vẫn phải tự gánh việc fetch, render, parse, kiểm tra schema, retry, quan sát hệ thống và quyết định tuân thủ.
Các giao diện đã được tài liệu hóa của Thunderbit nằm ở tầng cao hơn trong stack. Tài liệu Thunderbit mô tả trích xuất dựa trên URL với khả năng render và routing, còn Web Scraper API mô tả hai chế độ đầu ra: Markdown sạch từ một URL, hoặc JSON theo schema. Điều đó có thể giảm lượng hạ tầng crawler và parsing mà một đội phải vận hành. Nhưng nó không tạo ra thành công tuyệt đối với mọi target, không vượt qua kiểm soát truy cập, và cũng không tự quyết định việc thu thập có được phép hay không.
Hãy dùng giao diện proxy cấp thấp khi bạn cần kiểm soát trực tiếp hành vi truyền tải và sẵn sàng tự chịu trách nhiệm cho phần còn lại của crawler. Hãy dùng giao diện trích xuất cấp cao hơn khi nhu cầu thực sự là dữ liệu trang có cấu trúc và ranh giới dịch vụ đã tài liệu hóa phù hợp. Đó là những trách nhiệm kỹ thuật khác nhau, không phải hai thương hiệu của cùng một proxy.
Điểm chính cần nhớ
- HTTP proxy là một trung gian chuyển tiếp thông điệp, không phải tính năng tự động tạo riêng tư hay mã hóa.
- HTTP forwarding tường minh dùng absolute URI; HTTPS thường bắt đầu bằng yêu cầu
CONNECT host:portrồi chạy TLS qua tunnel. - Proxy dạng tunnel thường không thể đọc nội dung HTTP được TLS bảo vệ, nhưng một gateway chấm dứt TLS được cấp phép là một triển khai khác.
- Forward/reverse và explicit/interception là hai trục mô tả khác nhau.
- HTTP proxy, SOCKS5 và VPN nên được so sánh theo phạm vi traffic, cấu hình, mức độ tin cậy và chính sách định tuyến, không phải theo các khẳng định chung chung về tốc độ hay chi phí.
- Nếu không có quản trị viên đáng tin cậy hoặc ứng dụng chủ động cung cấp thông tin proxy, hãy để cài đặt proxy ở trạng thái tắt.
- Trong tự động hóa, hãy đặt việc dùng proxy thật rõ ràng, bảo vệ thông tin đăng nhập, hiểu các quy tắc bỏ qua và ưu tiên, và fail closed khi proxy là bắt buộc.
FAQs
HTTP proxy có giống VPN không?
Không. HTTP proxy cung cấp giao diện chuyển tiếp hoặc tunneling có hiểu HTTP cho các ứng dụng chọn dùng nó. VPN tạo một đường hầm mạng và thay đổi routing cho traffic được chính sách của nó bao gồm. Chỉ riêng nhãn gọi không chứng minh được ẩn danh, và split tunneling của VPN có nghĩa là phạm vi toàn thiết bị không phải lúc nào cũng có.
HTTP proxy có xem được traffic HTTPS không?
Trong một CONNECT tunnel thông thường, proxy chỉ chuyển tiếp các byte TLS và không thể đọc nội dung HTTP được bảo vệ. Tuy nhiên, nó vẫn có thể quan sát metadata của kết nối. Nếu một gateway được cấp phép chấm dứt TLS bằng CA mà client được quản lý tin cậy, nó có thể kiểm tra nội dung vì nó là một endpoint của hai kết nối TLS.
407 Proxy Authentication Required nghĩa là gì?
Proxy đang yêu cầu client cung cấp thông tin xác thực cho proxy. Nó khác với thử thách 401 do origin gửi ra. Hãy kiểm tra phương thức xác thực đã được phê duyệt và kênh bảo vệ phù hợp trước khi gửi thông tin đăng nhập.
HTTP proxy có ẩn IP của tôi không?
Origin thường nhìn thấy kết nối proxy như đối tác mạng trực tiếp của nó, nhưng điều đó không tự động tạo ra ẩn danh. Forwarded header, xác thực, cookie, dấu vân tay, hành vi DNS và log vẫn có thể xác định client.
Tôi có cần proxy để web scraping không?
Không phải lúc nào cũng cần. Câu trả lời phụ thuộc vào target đã được phép, lưu lượng request, yêu cầu theo khu vực, kiến trúc hệ thống và các quy tắc truy cập đã công bố của website. Proxy có thể cung cấp định tuyến và kiểm soát egress; nó không thay thế cho quyền truy cập, giới hạn tốc độ, phân tích dữ liệu, giám sát hay xử lý lỗi.
Vì sao một ứng dụng lại bỏ qua system proxy của tôi?
Các ứng dụng có thể dùng nguồn cấu hình và quy tắc ưu tiên khác nhau. Một app có thể theo OS, app khác lại dùng cài đặt riêng, còn công cụ dòng lệnh có thể đọc biến môi trường. Hãy kiểm tra tài liệu của ứng dụng đang lỗi và các quy tắc bỏ qua của nó thay vì giả định bảng cài đặt hệ thống kiểm soát tất cả.
Tìm hiểu thêm
