Ngày 27 tháng 7 năm 2026, đội ngũ Cloudflare Research đã công bố pvcli - một khách hàng dòng lệnh cho các giao thức mạng riêng tư. Về mặt hình thức, đây là "curl cho OHTTP": cùng một kiểu lệnh, nhưng thay vì thực hiện yêu cầu thông thường, công cụ này thu thập một trao đổi mã hóa ba bên, trong đó máy chủ nhận không thấy địa chỉ IP của bạn, và nút trung gian không thấy nội dung của yêu cầu. Mã nguồn được phát hành dưới giấy phép Apache 2.0, với kế hoạch hỗ trợ MASQUE và Privacy Pass.
Đối với ngành công nghiệp proxy, đây không phải là "một bản phát hành khác trên GitHub". Đây là cách đầu tiên thuận tiện để kiểm tra bộ giao thức mà Apple, Google, Mozilla và Meta đã âm thầm triển khai trong vài năm qua - và thường được giới thiệu như là "thay thế cho proxy". Chúng ta sẽ phân tích xem thực sự có gì ở đó và trả lời một cách trung thực câu hỏi chính: liệu bộ giao thức này có giải quyết được các vấn đề mà mọi người mua proxy cư trú và di động hay không. Spoiler: không, và lý do là do kiến trúc, chứ không phải "chưa đủ trưởng thành".
Cái gì đã được mở ra: pvcli trong chi tiết
pvcli được viết bằng Rust và có thể cài đặt bằng một lệnh thông qua cargo install --git. Theo README, đây là khách hàng HTTP/2 và HTTP/3 với hỗ trợ GET và POST, TLS 1.3 và mã hóa HPKE (RFC 9180). Chế độ chính - Oblivious HTTP: khách hàng chỉ định bước nhảy đầu tiên (relay) và cổng, trong khi công cụ tự thực hiện tất cả các phép toán mã hóa và đóng gói trong HTTP nhị phân.
- Yêu cầu thông thường:
pvcli https://example.com/cdn-cgi/trace, với cờ--http3- trên QUIC. - Chế độ OHTTP:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Proxy cổ điển:
pvcli -x https://proxy.example.com https://target.example.com- tức là HTTP CONNECT vẫn còn tồn tại.
Các tác giả đã cảnh báo một cách trung thực: phần mềm này là thử nghiệm và chưa qua kiểm toán, HPKE hậu lượng tử vẫn chưa được hỗ trợ, một số đặc tả thậm chí còn chưa trở thành RFC. Đây là một công cụ gỡ lỗi, không phải là một sản phẩm hoàn chỉnh cho sản xuất. Và chính vì lý do đó mà nó thú vị: trước đây, việc kiểm tra tích hợp OHTTP của người khác chỉ có thể thực hiện bằng mã của riêng bạn trên Swift hoặc Rust.
Oblivious HTTP: phân chia và không thống trị
OHTTP đã được chuẩn hóa như RFC 9458 vào ngày 12 tháng 1 năm 2024. Ý tưởng rất đơn giản nhưng tinh tế: phân tách kiến thức về "bạn là ai" và "bạn đang yêu cầu gì" giữa hai bên tham gia độc lập.
- Khách hàng mã hóa yêu cầu bằng một khóa tạm thời trên khóa công khai của cổng - một cặp khóa mới được tạo ra cho mỗi yêu cầu.
- Relay (relay mờ) thấy địa chỉ IP của bạn, nhưng nhận được văn bản mã hóa: nó không thể đọc được bạn đang hỏi về cái gì và ở đâu.
- Cổng giải mã yêu cầu và chuyển tiếp đến nguồn gốc, nhưng thấy địa chỉ IP của relay, chứ không phải của bạn.
Bảo đảm chính là unlinkability: nguồn gốc không thể liên kết hai yêu cầu của bạn với nhau. Hạn chế chính là sự tin tưởng: nếu relay và cổng thông đồng hoặc thuộc về một nhà điều hành, toàn bộ tính riêng tư sẽ bị phá hủy. NCC Group trong các cuộc kiểm toán đã chỉ ra những khó khăn thực tiễn - xoay vòng khóa, giới hạn tỷ lệ và độ trễ mạng.
Trong sản xuất, giao thức đã hoạt động và danh sách là ấn tượng:
- Apple - Private Cloud Compute cho các yêu cầu Apple Intelligence và Enhanced Visual Search trong "Ảnh"; hỗ trợ OHTTP trong Swift đã xuất hiện vào tháng 8 năm 2024.
- Google - Privacy Sandbox, k-anonymity và kiểm tra URL trong Safe Browsing mà không tiết lộ IP; Fastly đóng vai trò là relay.
- Mozilla - thu thập số liệu hiệu suất Firefox mà không xác định người dùng.
- Meta - Private Processing cho Meta AI trong WhatsApp (2025), cũng thông qua relay Fastly.
- Flo - "chế độ ẩn danh" của trình theo dõi chu kỳ dựa trên Cloudflare Privacy Gateway từ năm 2022.
Các cổng, ngoài Cloudflare và Fastly, còn được Internet Security Research Group triển khai trong dịch vụ Divvi Up. Điều này có nghĩa là cơ sở hạ tầng là có thật, không phải chỉ trên giấy.
MASQUE: đây mới thực sự giống như proxy
Phần thứ hai của bộ giao thức mà Cloudflare hứa hẹn sẽ thêm vào pvcli là MASQUE. Đây là một gia đình giao thức của nhóm làm việc IETF, chuyển việc proxy vào bên trong HTTP:
- RFC 9298 (tháng 8 năm 2022), CONNECT-UDP - proxy UDP bên trong HTTP; khách hàng gửi một CONNECT mở rộng với
:protocol: connect-udp, và proxy chuyển đổi các khung QUIC DATAGRAM thành các gói UDP. - RFC 9484 (tháng 10 năm 2023), CONNECT-IP - đã là một cấp độ IP hoàn chỉnh: các gói IP thô được đóng gói trong HTTP Datagrams, và máy chủ HTTP/3 trở thành một cổng VPN, có thể xử lý đồng thời TCP, UDP và ICMP.
Cả hai đặc tả đều yêu cầu một phương án dự phòng trên HTTP/2 nơi mà QUIC và UDP bị chặn ở cấp độ mạng, - điều này thường xảy ra trong các mạng doanh nghiệp và nhà cung cấp. Về cơ bản, MASQUE là những gì mà các "relay riêng tư" hiện đại của hệ điều hành được xây dựng, nơi mà lưu lượng đi qua hai bước nhảy độc lập: bước nhảy đầu tiên biết bạn, nhưng không biết người nhận, bước nhảy thứ hai thì ngược lại.
Privacy Pass: vé ẩn danh thay vì captcha
Viên gạch thứ ba - Privacy Pass, được chuẩn hóa qua ba tài liệu: RFC 9576 (kiến trúc), RFC 9577 (sơ đồ xác thực HTTP) và RFC 9578 (các giao thức phát hành token, có thể xác minh công khai và riêng tư). Logic trong hai bước: issuance - bạn một lần chứng minh rằng bạn là người hoặc khách hàng đáng tin cậy, và nhận một loạt token được ký mù; redemption - bạn trình bày token cho trang web, và nó cho phép bạn vào mà không cần captcha, không có khả năng liên kết token với thời điểm phát hành.
Đây chính là cơ chế đứng sau ý tưởng "cho phép bot tốt vào hợp pháp" - nó cũng nằm trong nền tảng của các đại lý đã ký và Web Bot Auth. Xu hướng là giống nhau: phân tách danh tính mạng (IP) và quyền truy cập (token, chữ ký).
Liệu điều này có thay thế proxy không? Phân tích không ảo tưởng
Mỗi lần có tin tức từ bộ giao thức này, lại xuất hiện luận điểm "tại sao cần proxy, nếu đã có OHTTP". Vấn đề là các giao thức riêng tư và proxy giải quyết các vấn đề khác nhau, và việc thay thế một cái bằng cái khác gặp phải bốn điểm khó khăn.
1. OHTTP chỉ hoạt động nơi mà trang web đã triển khai nó
Đây không phải là lớp phủ trên internet, mà là opt-in từ phía người nhận: cổng tự nâng cấp và cấu hình nguồn gốc (hoặc nhà thầu của nó). Bạn không thể "truy cập qua OHTTP" vào một thị trường hoặc mạng xã hội tùy ý - đơn giản là không có cổng. Tất cả các triển khai được liệt kê đều là các công ty che giấu IP của người dùng của chính họ khỏi các backend của chính họ. Đối với việc thu thập dữ liệu từ một trang web bên ngoài, cơ chế này không thể áp dụng về nguyên tắc.
2. Điểm ra - trung tâm dữ liệu, và mọi người đều biết điều đó
Ngay cả khi có cổng, yêu cầu ra ngoài sẽ xuất phát từ địa chỉ của Cloudflare, Fastly hoặc ISRG. Đây là các ASN nổi tiếng của các nhà cung cấp dịch vụ lưu trữ với các dải công khai. Các hệ thống chống bot xếp hạng IP theo loại mạng, và địa chỉ của relay đám mây nhận được cùng một điểm số như bất kỳ địa chỉ trung tâm dữ liệu nào khác. Bạn đã nhận được sự riêng tư từ nguồn gốc, nhưng "trông giống như một người dùng bình thường" thì không. Chính vì lý do này mà proxy cư trú với các địa chỉ thực tế của nhà cung cấp và các nhóm di động của các mạng CGNAT của nhà điều hành vẫn cần thiết.
3. Không có địa lý, xoay vòng và phiên dính
Cơ sở hạ tầng proxy cung cấp những gì mà các giao thức riêng tư không có theo thiết kế: lựa chọn quốc gia, khu vực và nhà điều hành, xoay vòng IP được quản lý, phiên dính trong một khoảng thời gian nhất định, các nhóm khác nhau cho các tài khoản khác nhau. OHTTP không cho phép bạn chọn "ra từ Đức, từ mạng của một ISP cụ thể" - không có khái niệm về điểm ra nào trong tầm tay bạn. Đối với việc kiểm tra phát hành địa phương, giá cả theo khu vực hoặc làm việc với nội dung bị giới hạn theo địa lý, đây là sự khác biệt không thể khắc phục.
4. Mô hình tin cậy khác nhau
OHTTP bảo vệ khỏi việc liên kết các yêu cầu với một nguồn gốc cụ thể, với điều kiện rằng relay và cổng là độc lập. Proxy bảo vệ khỏi việc trang web thấy địa chỉ thực của bạn và hồ sơ mạng của bạn. Điều đầu tiên liên quan đến sự riêng tư của dữ liệu và yêu cầu của người dùng, điều thứ hai liên quan đến quyền truy cập và phân phối tải. Các nhiệm vụ chỉ giao nhau một phần, và việc "chuyển" từ cái này sang cái kia là không thể.
Cái gì trong số này thực sự hữu ích trong thực tế
- Nếu bạn là nhà phát triển sản phẩm gửi dữ liệu telemetry hoặc yêu cầu đến API của mình - OHTTP qua Privacy Gateway hoặc Divvi Up thực sự giảm lượng dữ liệu cá nhân thu thập được và đơn giản hóa cuộc trò chuyện với luật sư. pvcli giờ đây cho phép bạn gỡ lỗi điều này mà không cần viết một khách hàng từ đầu.
- Nếu bạn thu thập dữ liệu công khai - bộ giao thức không thay đổi gì: điểm ra và danh tiếng của nó vẫn là nhiệm vụ của bạn. Đối với việc thu thập dữ liệu hàng loạt, sự kết hợp vẫn là - proxy trung tâm dữ liệu với xoay vòng trên các nền tảng thân thiện và proxy cư trú ở những nơi có hệ thống chống bot nghiêm ngặt.
- Nếu bạn làm việc với nhiều tài khoản - các giao thức riêng tư không giải quyết vấn đề cách ly: các phiên trên các nền tảng liên kết không chỉ qua IP, mà còn qua dấu vân tay trình duyệt và hành vi. Sự khác biệt giữa lớp IP và lớp danh tính đã được giải thích trong tài liệu về sự khác biệt giữa proxy và VPN.
- Nếu bạn tự động hóa quyền truy cập "hợp pháp" - đây là nơi bạn nên theo dõi cẩn thận. Privacy Pass và các đại lý đã ký đang hướng tới mô hình, nơi bot được cấp quyền truy cập dựa trên token đã trình bày, chứ không phải dựa trên "trông giống như con người". Đây là phần triển vọng nhất của tin tức.
Kết luận
Sự ra mắt của pvcli là một chỉ báo tốt về sự trưởng thành: các giao thức riêng tư đã ra khỏi giai đoạn nghiên cứu và có được các công cụ gỡ lỗi. OHTTP, MASQUE và Privacy Pass thực sự đang thay đổi cách mà internet xử lý địa chỉ của khách hàng, và trong vài năm tới, "trang web thấy địa chỉ IP của bạn" sẽ không còn là một định lý cho lưu lượng người dùng.
Nhưng đối với những người thu thập dữ liệu, quản lý nhiều tài khoản hoặc kiểm tra phát hành theo khu vực, mọi thứ vẫn không thay đổi. Các giao thức riêng tư che giấu bạn khỏi những người mà bạn đã đến theo lời mời. Proxy vẫn cần thiết ở những nơi không có lời mời - và ở đó, loại mạng, danh tiếng địa chỉ và chất lượng của nhóm vẫn quyết định tất cả. Thật hợp lý khi theo dõi Privacy Pass như một kênh hợp pháp cho bot trong tương lai và đồng thời duy trì một cơ sở hạ tầng proxy bình thường cho thực tế.
```