Dấu vân tay TCP/IP của proxy: Cách kiểm tra xem hệ điều hành có đang tiết lộ bạn cho anti-bot không

Bạn đã cấu hình trình duyệt chống phát hiện cho Windows và Chrome, chọn IP sạch, điều chỉnh múi giờ và ngôn ngữ, nhưng trang web vẫn yêu cầu captcha hoặc cắt tài khoản. Nguyên nhân phổ biến nằm ở dưới trình duyệt, ở cấp độ TCP/IP. Máy chủ thấy gói đầu tiên của kết nối (SYN), và từ các trường của nó có thể thấy hệ điều hành nào đã gửi gói này. Nếu đó là proxy Linux, trong khi User-Agent khai báo Windows, hệ thống chống bot nhận được sự mâu thuẫn mà không thể sửa chữa bằng tiêu đề.

Chủ đề này không còn là điều kỳ lạ. Vào ngày 13 tháng 10 năm 2026, theo dữ liệu từ Proxyway, nhà cung cấp Anh Byteful đã kích hoạt tính năng giả mạo dấu vân tay TCP/IP cho các proxy trung tâm dữ liệu và ISP trong phiên bản beta công khai: họ có thể tự nhận là Windows, macOS, Linux, Android và iOS. Giải thích của Proxyway rất đơn giản: các hệ thống chống bot ngày càng chú ý đến dấu vân tay TCP/IP. Dưới đây chúng ta sẽ phân tích cách kiểm tra này hoạt động, cách kiểm tra proxy của bạn trong năm phút và những gì cần làm khi có sự không khớp.

Dấu vân tay TCP/IP là gì và tại sao proxy lại thay đổi nó

Mỗi hệ điều hành thu thập gói SYN theo cách riêng: TTL khởi đầu của nó, kích thước cửa sổ TCP, hệ số mở rộng cửa sổ, MSS và, điều quan trọng nhất, tập hợp và thứ tự các tùy chọn TCP. Phương pháp nhận diện thụ động (công cụ cổ điển ở đây là p0f, các phiên bản hiện đại được gọi là Zardaxt và JA4T) đọc các trường này và đoán hệ điều hành mà không gửi gì cho khách hàng.

Điều quan trọng đối với những ai làm việc qua proxy: trang web thấy ngăn xếp TCP của máy tính mở kết nối cuối cùng đến nó. Proxy thông thường (HTTP CONNECT hoặc SOCKS5) nhận kết nối của bạn và mở một kết nối mới đến trang web từ tên của nó. Do đó, TTL và các tùy chọn TCP trong gói thuộc về proxy, không phải máy tính của bạn. Bạn có thể thay đổi User-Agent, dấu vân tay TLS hoặc tiêu đề, nhưng SYN đã được thu thập bởi nhân của máy mà bạn đang sử dụng để kết nối.

Giá trị điển hình theo hệ điều hành

Các điểm chuẩn từ phân tích của Scrapfly và tài liệu pydoll (trên các phiên bản nhân và mạng cụ thể, các giá trị có thể khác nhau):

• Windows 10/11: TTL khởi đầu 128, cửa sổ 64240–65535, thứ tự tùy chọn MSS, NOP, WSCALE, NOP, NOP, SACK (không có timestamp theo mặc định).
• Linux: TTL 64, cửa sổ 29200 trên các nhân 3.x+ (trên một số nhân 5.x/6.x 64240), thứ tự MSS, SACK, TIMESTAMP, NOP, WSCALE.
• macOS và iOS: TTL 64, cửa sổ 65535, thứ tự MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
• Android: TTL 64, thứ tự tùy chọn gần giống với Linux, điều này là hợp lý vì nó có nhân Linux.

Từ đó, cái bẫy chính: hầu hết các proxy trung tâm dữ liệu hoạt động trên Linux. Hồ sơ "Windows + Chrome" trên một proxy như vậy mang trong SYN các dấu hiệu của Linux, và sự mâu thuẫn này nổi bật nhất.

Độ chính xác của các hệ thống chống bot trong việc phát hiện sự không khớp

Các con số có trong dự án mở Zardaxt: đây là các phiên bản viết lại của p0f và satori.py, tìm kiếm chính xác các bộ lặp, tức là các proxy HTTP và SOCKS, mà qua đó trình duyệt tự nhận là một máy khác. Theo dữ liệu README cho bản dựng từ ngày 21 tháng 9 năm 2026 (cơ sở dữ liệu từ 1.453 dấu vân tay khoảng 23.000 phiên):

• mô hình với ngưỡng 0,8 phát hiện 94,4% kết nối qua proxy và chỉ đánh dấu sai 0,1% kết nối trực tiếp;
• nếu trình duyệt khai báo Windows, proxy bị phát hiện trong 96% trường hợp, nếu là Mac, thì 99%;
• điểm yếu là Android và Linux: chúng chia sẻ một lớp, vì vậy các bộ lặp như vậy bị phát hiện trong 74% trường hợp;
• VPN đường hầm mô hình hầu như không bị phát hiện (6,1%): qua đường hầm với trang web, ngăn xếp của thiết bị của bạn được hiển thị.

Hệ điều hành phát hiện rõ ràng thứ tự các tùy chọn TCP: trong phân tích nhân tố của dự án, trường này đoán hệ điều hành trong 99,1% trường hợp. Cờ DF gần như vô dụng (0,362). Đây là công cụ mở của một nhà nghiên cứu, còn các hệ thống chống bot thương mại không công bố chi tiết, nhưng nguyên tắc là giống nhau: so sánh hệ điều hành từ SYN với hệ điều hành từ User-Agent.

Cách kiểm tra proxy của bạn: từng bước một

1. Chụp "chuẩn" mà không có proxy. Mở trong trình duyệt thông thường browserleaks.com/tcp. Ghi lại TTL, MSS, thứ tự tùy chọn, suy đoán p0f và đánh giá Zardaxt về hệ điều hành. Đây là ngăn xếp thực tế của bạn.
2. Kiểm tra proxy từ console. Thực hiện yêu cầu qua proxy đến phân loại mở:
   curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
   Trong phản hồi sẽ có trường avg_score_os_class với điểm số cho Linux, Windows, Mac OS và iOS. Người chiến thắng ở đây là hệ điều hành của nút đầu ra của proxy, không phải máy tính của bạn.
3. Lặp lại trong hồ sơ chống phát hiện. Mở browserleaks.com/tcp hoặc proxydetect.live/tcpip.html trong hồ sơ với proxy. Bây giờ so sánh hai điều: hệ điều hành từ TCP/IP và hệ điều hành từ User-Agent của hồ sơ.
4. Xem xét MSS. Đường dây Ethernet sạch cung cấp MSS 1460. Các giá trị như 1380 (WireGuard), 1360 (IPsec) hoặc 1240 cho thấy có một đường hầm trên đường đi. Điều này không tự nó là một lệnh cấm, mạng di động cũng thường cung cấp MSS nhỏ hơn, nhưng kết hợp với các dấu hiệu khác sẽ tạo thêm nghi ngờ.
5. Thực hiện 5–10 lần đo trên vòng quay. Trên proxy cư trú và di động, mỗi IP mới có thể là một thiết bị khác với hệ điều hành khác. Một lần đo không nói lên điều gì, hãy xem phân phối.
6. Tổng hợp vào bảng: loại proxy → hệ điều hành theo TCP → hệ điều hành của hồ sơ → khớp hay không. Đây là câu trả lời cho việc hồ sơ nào nên chạy trên proxy nào.

Chỉ một TTL như bằng chứng không đủ: giá trị nhìn thấy giảm xuống trên mỗi bộ định tuyến, và trang web chỉ đánh giá giá trị khởi đầu (64 hoặc 128) theo bậc gần nhất. Sự kết hợp của các trường, trước hết là thứ tự tùy chọn, sẽ quyết định.

Phải làm gì khi có sự không khớp

1. Điều chỉnh hồ sơ theo proxy, không ngược lại

Cách rẻ nhất: chọn hệ điều hành của hồ sơ sao cho nó khớp với những gì nút đầu ra hiển thị. Nếu proxy cung cấp Linux, thì việc khởi chạy hồ sơ Linux là hợp lý hơn là cố gắng chứng minh với trang web rằng bạn đang sử dụng Windows. Đối với các nhiệm vụ mà hệ điều hành của hồ sơ không quan trọng (thu thập thông tin từ các trang công khai, theo dõi giá), điều này hoàn toàn giải quyết vấn đề.

2. Chọn loại proxy phù hợp với hệ điều hành cần thiết

• Proxy trung tâm dữ liệu gần như luôn hiển thị máy chủ Linux từ ASN đám mây. Điều này là bình thường cho việc thu thập thông tin từ khách hàng Linux (Python, Go, curl trên máy chủ): ngăn xếp và User-Agent của script của bạn đồng bộ. Đối với các hồ sơ "người dùng Windows", đây là điểm yếu. Proxy trung tâm dữ liệu hãy lấy ở nơi mà tốc độ và giá cho mỗi gigabyte quan trọng hơn là huyền thoại "người thật".
• Proxy cư trú đi qua các thiết bị và cổng gia đình thực tế, vì vậy trang web thấy ngăn xếp của nút người dùng thực sự. Hệ điều hành trên một IP cụ thể không được đảm bảo trước, nhưng đây là ngăn xếp của một thiết bị sống, không phải máy chủ đám mây. Đối với việc đa tài khoản và các hệ thống chống bot phức tạp, proxy cư trú cung cấp hình ảnh tự nhiên nhất, nếu kiểm tra phân phối hệ điều hành trên vòng quay.
• Proxy di động hiển thị các đường dẫn giống như Android hoặc iOS. Đối với các hồ sơ di động (mạng xã hội, ứng dụng, phiên bản di động của trang web), đây là sự khớp hoàn hảo trên tất cả các lớp. Để biết thêm về cách phân biệt IP di động thật với giả mạo, hãy đọc hướng dẫn kiểm tra proxy di động của chúng tôi. Đối với những nhiệm vụ như vậy, proxy di động 4G/5G là phù hợp.

3. Đừng nhầm lẫn lớp TCP với lớp TLS

Các công cụ như curl-impersonate hoặc curl_cffi giả mạo bắt tay TLS và HTTP/2 dưới Chrome, nhưng không chạm vào ngăn xếp TCP: SYN vẫn được thu thập bởi nhân của máy mà từ đó kết nối đi. Một dấu vân tay TLS tốt trên một TCP mâu thuẫn không cứu vãn được, cần cả hai lớp. Cách điều chỉnh phần TLS đã được thảo luận trong bài viết về vượt qua JA4 qua curl_cffi.

4. Giả mạo hệ điều hành ở phía proxy và đường hầm

Các nhà cung cấp bắt đầu bán việc giả mạo dấu vân tay TCP/IP trên các máy chủ của họ, ví dụ như Byteful ở trên, nhưng đây vẫn là điều hiếm hoi và beta. Cũng có con đường ngược lại: VPN đường hầm mô hình Zardaxt hầu như không bị phát hiện như một bộ lặp, vì trang web thấy ngăn xếp của chính bạn. Nhược điểm cũng đã được biết đến: MSS giảm sẽ phát hiện ra đường hầm, và IP của VPN thường được liệt kê trong cơ sở dữ liệu như một máy chủ lưu trữ.

Các lỗi thường gặp

• Chỉ kiểm tra bằng các công cụ kiểm tra IP. Các dịch vụ đánh giá IP nhìn vào địa chỉ và ASN, chứ không phải vào SYN. Một IP sạch với ngăn xếp Linux dưới hồ sơ Windows vượt qua công cụ kiểm tra và thất bại trên hệ thống chống bot.
• Rút ra kết luận từ một lần đo duy nhất trên vòng quay. Trên bể cư trú, IP tiếp theo có thể là một hệ điều hành khác.
• Sửa chữa bằng tiêu đề. Không có tiêu đề nào có thể viết lại SYN sau khi nhân đã gửi nó.
• Bỏ qua hồ sơ Android trên proxy Linux. Đối với các mô hình mở, đây là khu vực không xác định (74% bị phát hiện), nhưng các hệ thống chống bot thương mại có thể thêm các tín hiệu khác, như thời gian và ASN di động. Hồ sơ di động trông tự nhiên hơn trên IP di động.

Kết luận

Dấu vân tay TCP/IP là một lớp không thể sửa chữa từ trình duyệt: nó được xác định bởi máy mở kết nối đến trang web. Việc kiểm tra mất năm phút: browserleaks.com/tcp mà không có proxy và với proxy, cộng với curl đến phân loại mở. Quy tắc đơn giản tiếp theo: hệ điều hành của hồ sơ phải khớp với hệ điều hành của nút đầu ra. Trung tâm dữ liệu phù hợp với các script Linux, proxy cư trú cho các hồ sơ desktop "sống", và di động cho các kịch bản di động. Hãy chọn loại proxy phù hợp với hồ sơ của bạn, thực hiện 5–10 lần đo trên vòng quay, và hệ thống chống bot sẽ mất đi một trong những điểm gắn bó đáng tin cậy nhất.