您已为 Windows 和 Chrome 配置了反检测浏览器，选择了干净的 IP，调整了时区和语言，但网站仍然要求输入验证码或限制账户。常见原因在于浏览器之下，位于 TCP/IP 层。服务器看到连接的第一个数据包（SYN），通过其字段可以判断该数据包是由哪个操作系统发送的。如果是 Linux 代理服务器，而 User-Agent 声明为 Windows，反机器人系统会收到一个矛盾，这个矛盾无法通过头部信息来修复。
这个主题不再是异类。根据 Proxyway 的数据，英国提供商 Byteful 于 2026 年 10 月 13 日在公开测试中启用了数据中心和 ISP 代理的 TCP/IP 指纹伪装：它们能够伪装成 Windows、macOS、Linux、Android 和 iOS。Proxyway 的解释很简单：反机器人系统越来越多地关注 TCP/IP 指纹。下面我们将讨论这种检查是如何进行的，如何在五分钟内检查您的代理，以及在不匹配时该怎么办。
什么是 TCP/IP 指纹以及代理为何要更改它
每个操作系统以不同的方式收集 SYN 数据包：其初始 TTL、TCP 窗口大小、窗口缩放因子、MSS，以及最重要的，TCP 选项的集合和顺序。被动指纹识别（经典工具是 p0f，现代变体称为 Zardaxt 和 JA4T）读取这些字段并猜测操作系统，而不向客户端发送任何响应。
对于通过代理工作的人来说，关键点是：网站看到的是打开最后一个连接的机器的 TCP 堆栈。普通代理（HTTP CONNECT 或 SOCKS5）接受您的连接，并以自己的名义打开到网站的新连接。因此，数据包中的 TTL 和 TCP 选项属于代理，而不是您的计算机。可以更改 User-Agent、TLS 指纹或头部信息，但 SYN 已经由您所连接的机器的内核收集。
操作系统的典型值
来自 Scrapfly 的分析 和 pydoll 文档的参考值（具体内核和网络的值可能有所不同）：
- Windows 10/11：初始 TTL 128，窗口 64240–65535，选项顺序 MSS、NOP、WSCALE、NOP、NOP、SACK（默认情况下不带时间戳）。
- Linux：TTL 64，窗口 29200 在 3.x+ 内核上（在部分 5.x/6.x 内核上为 64240），选项顺序 MSS、SACK、TIMESTAMP、NOP、WSCALE。
- macOS 和 iOS：TTL 64，窗口 65535，选项顺序 MSS、NOP、WSCALE、NOP、NOP、TIMESTAMP、SACK、EOL。
- Android：TTL 64，选项顺序接近 Linux，这很合理，因为它的内核是 Linux。
因此，主要的陷阱是：几乎所有数据中心代理都运行在 Linux 上。“Windows + Chrome” 的配置在这样的代理上会在 SYN 中显示 Linux 的特征，这种矛盾最为明显。
反机器人系统捕捉不匹配的准确性
开放项目 Zardaxt 提供了一些数据：这是重写的 p0f 和 satori.py，专门寻找转发器，即 HTTP 和 SOCKS 代理，浏览器在其后伪装成另一台机器。根据 2026 年 9 月 21 日的构建 README（基于约 23000 个会话的 1453 个指纹）：
- 阈值为 0.8 的模型捕获 94.4% 的代理连接，并错误标记仅 0.1% 的直接连接；
- 如果浏览器声明为 Windows，代理在 96% 的情况下被捕获，如果是 Mac，则为 99%；
- 弱点在于 Android 和 Linux：它们共享一个类别，因此这些转发器在 74% 的情况下被捕获；
- 隧道 VPN 模型几乎无法被捕获（6.1%）：通过隧道与网站的连接显示的是您自己设备的堆栈。
操作系统最明显地显示了 TCP 选项的顺序：在项目的因子分析中，这个字段在 99.1% 的情况下猜测出操作系统。DF 标志几乎没有用（0.362）。这是一个研究者的开放工具，商业反机器人系统的细节未公开，但原理相同：比较 SYN 中的操作系统与 User-Agent 中的操作系统。
如何检查您的代理：逐步指南
- 在没有代理的情况下获取“基准”。 在普通浏览器中打开 browserleaks.com/tcp。记录 TTL、MSS、选项顺序、p0f 的猜测和 Zardaxt 对操作系统的评估。这是您的真实堆栈。
- 从控制台检查代理。 通过代理向开放分类器发送请求：
curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
响应中将包含avg_score_os_class字段，显示 Linux、Windows、Mac OS 和 iOS 的得分。这里的赢家是代理的出口节点操作系统，而不是您的计算机。 - 在反检测配置文件中重复操作。 在带有代理的配置文件中打开 browserleaks.com/tcp 或 proxydetect.live/tcpip.html。现在比较两个方面：TCP/IP 中的操作系统和配置文件中的 User-Agent。
- 查看 MSS。 干净的以太网线路提供 MSS 1460。像 1380（WireGuard）、1360（IPsec）或 1240 的值表示路径上有隧道。单独来看这不是禁令，移动网络也常常提供较小的 MSS，但与其他特征结合时会增加怀疑。
- 进行 5–10 次轮换测量。 在居民和移动代理中，每个新 IP 可能是另一台具有不同操作系统的设备。一次测量并不能说明问题，观察分布。
- 汇总成表： 代理类型 → TCP 操作系统 → 配置文件操作系统 → 是否匹配。这个就是答案，告诉您在什么代理上运行哪个配置文件。
单个 TTL 作为证据是不够的：可见值在每个路由器上都会减少，网站仅根据最近的幂次评估初始值（64 或 128）。解决方案是字段的组合，首先是选项顺序。
不匹配时该怎么办
1. 调整配置文件以适应代理，而不是反过来
最便宜的方法是选择配置文件的操作系统，使其与出口节点显示的操作系统相匹配。如果代理提供 Linux，启动 Linux 配置文件比向网站证明您是 Windows 更诚实。对于操作系统不重要的任务（解析公共页面、监控价格），这完全解决了问题。
2. 根据所需操作系统选择代理类型
- 数据中心代理几乎总是显示来自云 ASN 的 Linux 服务器。这对于使用 Linux 客户端（Python、Go、curl 在服务器上）进行抓取是正常的：您的脚本的堆栈和 User-Agent 是一致的。对于“Windows 用户”配置文件来说，这是一个薄弱环节。数据中心代理应选择那些速度和每 GB 价格重要，而不是“真人”传说。
- 居民代理通过真实的家庭设备和网关连接，因此网站看到的是实际用户节点的堆栈。特定 IP 的操作系统并不保证，但这是一个真实设备的堆栈，而不是云服务器。对于多账户和复杂的反机器人，居民代理提供了最自然的图像，如果检查操作系统在轮换中的分布。
- 移动代理显示的路径类似于 Android 或 iOS。对于移动配置文件（社交网络、应用程序、网站的移动版本），这是各层之间的完美匹配。有关如何区分真实的蜂窝 IP 和伪造的，请参阅我们的移动代理检查指南。对于这些任务，适合使用移动 4G/5G 代理。
3. 不要混淆 TCP 层和 TLS 层
像 curl-impersonate 或 curl_cffi 这样的工具伪装 TLS 握手和 HTTP/2 为 Chrome，但不触及 TCP 堆栈：SYN 仍然由发起连接的机器的内核收集。良好的 TLS 指纹在矛盾的 TCP 上并不能拯救，需要两个层次。如何调整 TLS 部分，在关于通过 curl_cffi 绕过 JA4的文章中进行了讨论。
4. 代理端的操作系统伪装和隧道
提供商开始在其服务器上销售 TCP/IP 指纹伪装，Byteful 的例子如上，但这仍然是稀有和测试版。还有另一种方式：隧道 VPN 模型 Zardaxt 几乎不会被捕获为转发器，因为网站看到的是您自己的堆栈。缺点也很明显：减少的 MSS 显示隧道，而 VPN 的 IP 常常在数据库中被列为托管。
常见错误
- 仅通过 IP 检查。 IP 声誉服务查看地址和 ASN，而不是 SYN。干净的 IP 在 Windows 配置文件下通过检查器，但在反机器人系统中失败。
- 根据轮换中的一次测量得出结论。 在居民池中，下一个 IP 可能是另一种操作系统。
- 通过头部信息进行修复。 在内核发送 SYN 后，没有任何头部可以重写它。
- 忽视 Linux 代理上的 Android 配置文件。 对于开放模型，这是一个不确定区域（74% 的捕获率），但商业反机器人可能会添加其他信号，如时序和移动 ASN。移动配置文件在移动 IP 上看起来更自然。
总结
TCP/IP 指纹是一个无法通过浏览器修复的层次：它由打开与网站连接的机器确定。检查只需五分钟：在没有代理和有代理的情况下使用 browserleaks.com/tcp，加上对开放分类器的 curl 请求。接下来的简单规则是：配置文件的操作系统必须与出口节点的操作系统匹配。数据中心适合 Linux 脚本，居民代理适合“真实”的桌面配置文件，移动代理适合移动场景。根据您的配置文件选择代理类型，进行 5–10 次轮换测量，反机器人将失去最可靠的抓手之一。