代理检测原理：网站如何用延迟差判断你的连接经过了代理中转
网站用延迟做代理检测，靠的是同一次访问里两段时间对不上：服务器从 TCP 连接上量到的往返时间，只覆盖"代理出口到服务器"这一段；页面里的脚本量到的往返时间，覆盖的是"你的设备到服务器"的完整路径。直连时两者接近，中间多了一层中转，后者会明显大于前者。这是一个概率信号，通常要和 IP 类型、DNS、时区等其他线索一起看，单独拿出来并不能下结论。
本文是隐私科普，帮你理解自己的网络在别人眼里是什么样子，不讨论如何绕过任何平台的检测或风控；使用各类服务时请遵守其服务条款和当地法规。
服务器能量到哪一段延迟？
建立 TCP 连接要三次握手：客户端发 SYN，服务器回 SYN-ACK，客户端再回 ACK。服务器从发出 SYN-ACK 到收到 ACK 的间隔，就是一次往返时间（RTT）。之后的数据传输中，内核也会持续根据确认包更新 RTT 估计值。
要看的是这条 TCP 连接的另一端是谁：
- 直连时，TCP 的另一端就是你的电脑或手机，服务器量到的是你到它的往返。
- 经过代理时，TCP 连接由代理出口发起，服务器量到的是"代理出口 ↔ 服务器"的往返。你的设备到代理之间那一段，服务器在 TCP 层看不到。
很多 CDN 和边缘平台会把这个值暴露给业务代码。例如 Cloudflare Workers 的请求对象里有客户端 TCP RTT 字段（request.cf.clientTcpRtt，见 Cloudflare 官方文档），网站不需要自己抓包，就能拿到"连过来的那个 IP 离我多远"。
浏览器里又能量到哪一段？
页面加载后，脚本可以自己计时：连续发几个小请求（fetch 或 WebSocket 消息），记录发出到收到响应的时间，取中位数。这是应用层往返，路径是：
你的设备 → 本地网络 → 代理入口 → 代理出口 → 服务器 → 原路返回
它包含了 TCP 层看不到的那一段，还会多出一些应用层开销：浏览器调度、TLS 记录处理、代理软件本身的转发耗时。
所以网站手里有两个数：
| 测量位置 | 量到的路径 | 是否包含"设备到代理"这一段 |
|---|---|---|
| 服务器 TCP 层 | 代理出口 ↔ 服务器 | 不包含 |
| 浏览器应用层 | 设备 ↔ 代理 ↔ 服务器 | 包含 |
为什么中转会把差距拉大？
假设一个例子（数字仅作示意）：你在上海，代理出口在美国西海岸，服务器的边缘节点也在美国西海岸。
- 服务器 TCP 层看到：出口和边缘节点在同一个城市，往返只有几毫秒。
- 浏览器应用层看到：数据要先从上海跨太平洋到出口，再到服务器，往返一两百毫秒。
一边几毫秒，一边一两百毫秒，这个差距用"应用层开销"解释不了。直连的情况下，两段测的是同一条路径，差值通常只来自浏览器和 TLS 的额外处理，量级小得多。
背后是物理限制：光在光纤里大约每毫秒走 200 公里，实际线路还要绕路和经过路由器排队。一个自称在某城市的 IP，如果从浏览器量出的往返远超这个城市到服务器的合理范围，就说明数据在别处"多走了一段"。
一些网站还会做反向推算：已知出口 IP 的地理位置，再用应用层往返估算"真实设备大概离服务器多远"。数据只够画一个大致的圈，但圈和 IP 宣称的位置差太远，同样是疑点。
延迟差一定说明在用代理吗？
不一定。下面这些情况都会让应用层往返偏大，属于常见误判来源：
- 移动网络和弱 Wi-Fi：空口重传、信号切换会让应用层往返抖动很大，而 TCP 初次握手可能恰好量在空闲时刻。
- 缓冲区膨胀（bufferbloat）：家里有人在下载大文件时，路由器队列塞满，应用层请求排队变慢。
- 企业网关、安全软件：公司出口的透明代理、杀毒软件的 HTTPS 检查，本身就是一层中转，会产生和代理类似的特征，但用户主观上并没有"用代理"。
- 卫星网络和偏远地区线路：本身往返就大。
- 浏览器后台限流：页面在后台标签时，计时器和网络请求可能被降速，测出的值不准。
所以比较认真的检测方会多测几次、取中位数，再把延迟差作为一项加权信号，而不是单独据此封禁。这也是为什么同一个网络在不同网站上的检测结论可能不同，原因和为什么不同网站测出的 IP 纯净度不一样类似：样本、阈值、权重都不一样。
除了延迟，代理检测还看哪些信号？
延迟只是其中一类。实际的代理检测一般会把下面几类信号叠在一起看：
IP 本身的属性
- IP 类型和 ASN：出口属于云厂商、托管机房，还是家庭宽带、移动网络。机房段被标记为"可能是代理"的概率天然更高，详见机房 IP 和家宽 IP 有什么区别。
- 信誉记录：是否出现在公开的代理列表、Tor 出口列表、DNS 黑名单里。cdnping 的 /ip 汇总了 14 个信誉来源，每项命中都公开权重，计算方式见 IP 纯净度怎么算。
网络层特征
- TCP/IP 协议栈指纹：SYN 包里的 TTL、窗口大小、选项顺序等，会带出操作系统特征。浏览器 User-Agent 说是 Windows，TCP 指纹却像 Linux 服务器，就说明连接可能由另一台机器发起。cdnping 的 /ip 里有一项“内核版本反推”（23 项特征），可以和浏览器自报的系统对照着看。
- MSS/MTU 偏小：隧道协议要加封装头，留给数据的空间变小，握手里通告的 MSS 往往低于常见以太网值。
- 多个出口不一致：同一个浏览器访问不同站点时出口 IP 不同，或者 IPv4 和 IPv6 走了不同路径。双栈场景的细节可以看 IPv6 代理不生效。
泄漏类信号
- DNS 泄漏：网页里触发的 DNS 查询由哪个解析器发出，和出口 IP 是否在同一个国家或网络。
- WebRTC 泄漏：浏览器通过 STUN 暴露的本地或公网地址，和 HTTP 出口不一致。原理见 /learn/dns-leak-webrtc-leak，各浏览器里的相关设置见 WebRTC 泄漏怎么关。
环境一致性
- 时区、语言、字体：系统时区和 IP 所在地对不上、语言列表和地区不搭，单项意义有限，多项叠加时权重会上升。逐项解释见浏览器指纹与环境检测。
还有一类比较特别：国内网站能通过自家 CDN 拿到你访问国内资源时的客户端 IP，和访问境外资源的出口一对比，就能看出是否分流。这部分在国内网站如何看到你的真实 IP里单独讲过。
自己怎么看这项指标？
下面几步只用来了解自己的网络状况，不涉及任何绕过手段。
第一步：在 cdnping 上看延迟特征
打开 /ip，找到"延迟特征"一项。它做的事情就是本文描述的对比：浏览器里测得的往返，和 Cloudflare 在边缘测得的出口 TCP 往返放在一起。看结果时注意三点：
- 两个数分别是多少，差值大约多少。
- 页面保持在前台，别同时开下载；必要时刷新两三次，看结论是否稳定。
- 和同一页面上的 IP 类型、DNS 泄漏、WebRTC 结果对照着看，而不是只看这一项。
检测口径和数据处理方式写在 /methodology。
第二步：用 curl 粗看连接各阶段耗时
在终端里运行：
curl -o /dev/null -s -w 'dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\n' https://cdnping.org/
tcp减去dns，大致是你本机看到的一次 TCP 往返。- 如果系统层面配置了代理，curl 默认可能会读取环境变量
https_proxy。这时 TCP 握手是和代理建立的，tcp那一项会很小，而tls、ttfb才反映完整路径。这正好可以直观感受"连接另一端是谁"决定了你量到什么。
想进一步理解连接建立、网关往返和首 token 的区别，可以看 AI API 延迟拆解。
第三步：对照下表理解结果
| 你看到的情况 | 更可能的解释 | 建议下一步 |
|---|---|---|
| 浏览器往返与出口 TCP 往返接近 | 直连，或代理出口离你很近 | 结合 IP 类型确认 |
| 浏览器往返明显大于出口 TCP 往返，多次一致 | 存在中转（个人代理、公司网关或安全软件） | 确认自己是否在公司网络、是否装了 HTTPS 检查类软件 |
| 差值时大时小，结论来回变 | 网络抖动、Wi-Fi 或移动信号不稳 | 换有线或空闲时段再测 |
| 延迟正常但 DNS 或 WebRTC 显示另一个地区 | 分流或泄漏，与延迟无关 | 看 /learn/split-tunneling 了解分流 |
延迟检测的局限
延迟对比只回答一个问题：连过来的 IP 离服务器多近，你本人离服务器多远，两个距离对不对得上。它只靠计时，不读取本地信息，页面层面没有开关可关；同时它受网络质量影响大，误判场景不少。
排查"某个网站觉得我的网络环境异常"时，把 IP 属性、泄漏、环境一致性和延迟几类结果放在一起看。完整的自检顺序可以参考开发者网络自检清单（2026 版）。
