---
title: "代理检测原理：网站如何用延迟差判断你的连接经过了代理中转"
description: "讲清网站做代理检测时怎样对比 TCP 往返和浏览器往返，为什么中转会拉大两者差距，还有哪些信号会一起参与判断，以及怎样用 curl 和 cdnping 自查并读懂结果。"
url: https://cdnping.org/blog/how-sites-detect-proxy-by-latency
language: zh-CN
published: 2026-10-20
category: "IP 与隐私"
tags: ["代理检测","网络延迟","TCP","隐私","浏览器指纹"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 代理检测原理：网站如何用延迟差判断你的连接经过了代理中转

网站用延迟做代理检测，靠的是同一次访问里两段时间对不上：服务器从 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 官方文档](https://developers.cloudflare.com/workers/runtime-apis/request/)），网站不需要自己抓包，就能拿到"连过来的那个 IP 离我多远"。

## 浏览器里又能量到哪一段？

页面加载后，脚本可以自己计时：连续发几个小请求（`fetch` 或 WebSocket 消息），记录发出到收到响应的时间，取中位数。这是应用层往返，路径是：

```
你的设备 → 本地网络 → 代理入口 → 代理出口 → 服务器 → 原路返回
```

它包含了 TCP 层看不到的那一段，还会多出一些应用层开销：浏览器调度、TLS 记录处理、代理软件本身的转发耗时。

所以网站手里有两个数：

| 测量位置 | 量到的路径 | 是否包含"设备到代理"这一段 |
|---|---|---|
| 服务器 TCP 层 | 代理出口 ↔ 服务器 | 不包含 |
| 浏览器应用层 | 设备 ↔ 代理 ↔ 服务器 | 包含 |

## 为什么中转会把差距拉大？

假设一个例子（数字仅作示意）：你在上海，代理出口在美国西海岸，服务器的边缘节点也在美国西海岸。

- 服务器 TCP 层看到：出口和边缘节点在同一个城市，往返只有几毫秒。
- 浏览器应用层看到：数据要先从上海跨太平洋到出口，再到服务器，往返一两百毫秒。

一边几毫秒，一边一两百毫秒，这个差距用"应用层开销"解释不了。直连的情况下，两段测的是同一条路径，差值通常只来自浏览器和 TLS 的额外处理，量级小得多。

背后是物理限制：光在光纤里大约每毫秒走 200 公里，实际线路还要绕路和经过路由器排队。一个自称在某城市的 IP，如果从浏览器量出的往返远超这个城市到服务器的合理范围，就说明数据在别处"多走了一段"。

一些网站还会做反向推算：已知出口 IP 的地理位置，再用应用层往返估算"真实设备大概离服务器多远"。数据只够画一个大致的圈，但圈和 IP 宣称的位置差太远，同样是疑点。

## 延迟差一定说明在用代理吗？

不一定。下面这些情况都会让应用层往返偏大，属于常见误判来源：

- **移动网络和弱 Wi-Fi**：空口重传、信号切换会让应用层往返抖动很大，而 TCP 初次握手可能恰好量在空闲时刻。
- **缓冲区膨胀（bufferbloat）**：家里有人在下载大文件时，路由器队列塞满，应用层请求排队变慢。
- **企业网关、安全软件**：公司出口的透明代理、杀毒软件的 HTTPS 检查，本身就是一层中转，会产生和代理类似的特征，但用户主观上并没有"用代理"。
- **卫星网络和偏远地区线路**：本身往返就大。
- **浏览器后台限流**：页面在后台标签时，计时器和网络请求可能被降速，测出的值不准。

所以比较认真的检测方会多测几次、取中位数，再把延迟差作为一项加权信号，而不是单独据此封禁。这也是为什么同一个网络在不同网站上的检测结论可能不同，原因和[为什么不同网站测出的 IP 纯净度不一样](/blog/why-ip-purity-sites-disagree)类似：样本、阈值、权重都不一样。

## 除了延迟，代理检测还看哪些信号？

延迟只是其中一类。实际的代理检测一般会把下面几类信号叠在一起看：

### IP 本身的属性

- **IP 类型和 ASN**：出口属于云厂商、托管机房，还是家庭宽带、移动网络。机房段被标记为"可能是代理"的概率天然更高，详见[机房 IP 和家宽 IP 有什么区别](/blog/datacenter-ip-vs-residential-ip)。
- **信誉记录**：是否出现在公开的代理列表、Tor 出口列表、DNS 黑名单里。cdnping 的 [/ip](/ip) 汇总了 14 个信誉来源，每项命中都公开权重，计算方式见 [IP 纯净度怎么算](/blog/ip-purity-score-explained)。

### 网络层特征

- **TCP/IP 协议栈指纹**：SYN 包里的 TTL、窗口大小、选项顺序等，会带出操作系统特征。浏览器 User-Agent 说是 Windows，TCP 指纹却像 Linux 服务器，就说明连接可能由另一台机器发起。cdnping 的 [/ip](/ip) 里有一项“内核版本反推”（23 项特征），可以和浏览器自报的系统对照着看。
- **MSS/MTU 偏小**：隧道协议要加封装头，留给数据的空间变小，握手里通告的 MSS 往往低于常见以太网值。
- **多个出口不一致**：同一个浏览器访问不同站点时出口 IP 不同，或者 IPv4 和 IPv6 走了不同路径。双栈场景的细节可以看 [IPv6 代理不生效](/blog/ipv6-dual-stack-proxy-mismatch)。

### 泄漏类信号

- **DNS 泄漏**：网页里触发的 DNS 查询由哪个解析器发出，和出口 IP 是否在同一个国家或网络。
- **WebRTC 泄漏**：浏览器通过 STUN 暴露的本地或公网地址，和 HTTP 出口不一致。原理见 [/learn/dns-leak-webrtc-leak](/learn/dns-leak-webrtc-leak)，各浏览器里的相关设置见 [WebRTC 泄漏怎么关](/blog/fix-webrtc-leak-chrome-firefox-safari)。

### 环境一致性

- **时区、语言、字体**：系统时区和 IP 所在地对不上、语言列表和地区不搭，单项意义有限，多项叠加时权重会上升。逐项解释见[浏览器指纹与环境检测](/blog/browser-environment-consistency)。

还有一类比较特别：国内网站能通过自家 CDN 拿到你访问国内资源时的客户端 IP，和访问境外资源的出口一对比，就能看出是否分流。这部分在[国内网站如何看到你的真实 IP](/blog/how-chinese-sites-see-your-real-ip)里单独讲过。

## 自己怎么看这项指标？

下面几步只用来了解自己的网络状况，不涉及任何绕过手段。

### 第一步：在 cdnping 上看延迟特征

打开 [/ip](/ip)，找到"延迟特征"一项。它做的事情就是本文描述的对比：浏览器里测得的往返，和 Cloudflare 在边缘测得的出口 TCP 往返放在一起。看结果时注意三点：

1. 两个数分别是多少，差值大约多少。
2. 页面保持在前台，别同时开下载；必要时刷新两三次，看结论是否稳定。
3. 和同一页面上的 IP 类型、DNS 泄漏、WebRTC 结果对照着看，而不是只看这一项。

检测口径和数据处理方式写在 [/methodology](/methodology)。

### 第二步：用 curl 粗看连接各阶段耗时

在终端里运行：

```bash
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 延迟拆解](/blog/api-latency-connect-rtt-ttft)。

### 第三步：对照下表理解结果

| 你看到的情况 | 更可能的解释 | 建议下一步 |
|---|---|---|
| 浏览器往返与出口 TCP 往返接近 | 直连，或代理出口离你很近 | 结合 IP 类型确认 |
| 浏览器往返明显大于出口 TCP 往返，多次一致 | 存在中转（个人代理、公司网关或安全软件） | 确认自己是否在公司网络、是否装了 HTTPS 检查类软件 |
| 差值时大时小，结论来回变 | 网络抖动、Wi-Fi 或移动信号不稳 | 换有线或空闲时段再测 |
| 延迟正常但 DNS 或 WebRTC 显示另一个地区 | 分流或泄漏，与延迟无关 | 看 [/learn/split-tunneling](/learn/split-tunneling) 了解分流 |

## 延迟检测的局限

延迟对比只回答一个问题：连过来的 IP 离服务器多近，你本人离服务器多远，两个距离对不对得上。它只靠计时，不读取本地信息，页面层面没有开关可关；同时它受网络质量影响大，误判场景不少。

排查"某个网站觉得我的网络环境异常"时，把 IP 属性、泄漏、环境一致性和延迟几类结果放在一起看。完整的自检顺序可以参考[开发者网络自检清单（2026 版）](/blog/developer-network-self-check-2026)。