看到 301、302、307 或 308 时，不能只说“网站跳转了”。这些状态码对后续请求方法的处理并不完全相同，登录、订阅下载或接口请求经过代理时，方法是否被保留会直接影响排障结论。
## 先分清两类跳转
301 和 302 历史上常被客户端用于把 POST 改成 GET；303 明确指向用 GET 获取另一个资源。307 和 308 则要求自动重定向时不要改变原请求方法。浏览器和命令行工具还可能为了兼容旧站点采用不同处理方式，所以不能只凭最终页面正常就推断中间请求完全相同。
## 先画出重定向链
对你有权访问的公开测试地址，先不跟随跳转：
```powershell
curl.exe -sS -o NUL `
-w "code=%{response_code} next=%{redirect_url}\n" `
"https://example.com/old-path"
```
再允许有限次数的跳转，并记录最终地址：
```powershell
curl.exe -L --max-redirs 5 -sS -o NUL `
-w "code=%{response_code} redirects=%{num_redirects} final=%{url_effective}\n" `
"https://example.com/old-path"
```
这里使用无敏感信息的 GET 请求做观察。不要把订阅链接、登录令牌或表单内容粘进公开命令记录。
## 为什么这与机场排障有关
节点只负责传输时，跳转通常由目标站点返回；但代理规则、DNS 或 HTTPS 检查异常可能让某一跳失败。先画出重定向链，再讨论节点，才能知道失败发生在原地址、跳转目标还是方法变化之后。
若只有带表单的请求失败，应由站点自身日志或开发者工具核对方法，不要用反复提交真实表单来试错。机场测评中也不应把一次 302 后成功写成“所有接口都兼容”。
## 验收标准
记录应包含首个状态码、每一跳的目标域名、跳转次数和最终状态。更换节点后仍在同一跳失败，优先检查目标站点与请求方法；只有失败位置随节点稳定变化，才继续调查线路或分流。
## 参考资料
- [RFC 9110：HTTP 语义与重定向状态码](https://www.rfc-editor.org/rfc/rfc9110.html)
- [curl 官方手册：--location、--max-redirs 与重定向变量](https://curl.se/docs/manpage.html)
区分301、302、303、307和308对请求方法的处理，用curl记录重定向链后再判断代理或节点问题。
TLS 1.3 的 0-RTT 常被理解成“省掉一次往返，所以一定更快”。它实际上依赖此前连接留下的 PSK 或会话票据，服务器可以接受、拒绝或要求重新握手，而且早期数据带有需要应用层处理的重放风险。
## 0-RTT 省掉了什么
普通首次连接需要先完成握手，再发送应用数据。恢复连接时，客户端可能在第一批消息中携带早期数据，因此在合适条件下减少等待。但 RFC 8446 规定，服务器仍可忽略早期数据并回退到常规 1-RTT，也可以通过 HelloRetryRequest 要求客户端重新开始。
所以看到“TLS 1.3”并不能证明正在使用 0-RTT；第二次访问更快，也可能来自会话恢复、连接复用、DNS 缓存或浏览器缓存。
## 为什么有重放风险
RFC 8446 明确指出，TLS 本身不为 0-RTT 数据提供固有的重放保护。攻击者可能复制早期数据，客户端重试也可能让服务器收到重复的应用消息。因此应用不得把不适合重复执行的操作随意放进早期数据。
对读者最实用的判断是：普通只读请求即使被重复，后果通常较容易控制；提交订单、修改账户或发送消息等有副作用的请求，不应因为追求少一次往返而假定可以安全重放。
## 机场节点测试怎样避免误判
1. 先完全关闭测试程序，做一次冷启动连接。
2. 在同一进程内连续请求同一授权目标，记录热连接结果。
3. 分别记录 DNS、TCP、TLS 和首字节时间，不只看总时间。
4. 换节点后重复同样顺序，避免把缓存命中算成线路优势。
5. 不对登录、支付或任何会改变服务器状态的接口做 0-RTT 实验。
代理协议、节点入口和目标网站的 TLS 是不同层。机场节点可能改善网络往返，但是否启用 0-RTT 由客户端、服务器和应用协议共同决定。
## 验收结论怎么写
测评应分别报告首次连接和连续访问，不把“第二次更快”直接归因于 0-RTT，也不把 0-RTT 写成服务商独有能力。确认不了早期数据是否被接受时，就只描述可观察到的握手与请求时间。
来源：[RFC 8446：TLS 1.3 早期数据与 0-RTT 重放风险](https://www.rfc-editor.org/rfc/rfc8446.html)。
说明TLS 1.3早期数据如何依赖会话恢复、服务器为何可能拒绝，以及0-RTT重放风险对测试结论的限制。
# HTTPS 显示 h2 是怎样协商的？看懂 TLS ALPN
浏览器开发者工具或 curl 输出中的 `h2`，表示这条连接使用 HTTP/2。它通常不是通过网页响应头临时决定的，而是在 TLS 握手期间借助 ALPN（Application-Layer Protocol Negotiation）完成协商。
理解 ALPN 能帮助排查一种常见现象：同一网站直连显示 h2，经过某个代理路径后却显示 HTTP/1.1。这个差异只是协议协商结果，不能单独证明节点快慢、UDP 支持或服务质量。
## ALPN 在哪一层工作
RFC 7301 定义了 TLS 中的应用层协议协商扩展。客户端在握手时列出支持的协议，服务器从双方都支持的协议中选择一个。对于 HTTPS，常见标识包括 `h2` 和 `http/1.1`。
它和前一天讲过的 SNI 作用不同：SNI帮助服务器选择主机名对应的证书和站点，ALPN选择 TLS 建立后使用的应用层协议。两者都发生在 HTTP 正文传输之前。
## 用 curl 做单次验证
```bash
curl -sS -o NUL -w "http=%{http_version}\n" https://example.com/
```
macOS 或 Linux 把 `NUL` 换成 `/dev/null`。把示例域名替换为你有权访问的公开 HTTPS 目标。也可以分别限制协议做对照：
```bash
curl --http1.1 -I https://example.com/
curl --http2 -I https://example.com/
```
如果本机 curl 未编译 HTTP/2 支持，第二条命令会直接报错；这属于客户端能力，不应归因于机场节点。先用 `curl --version` 查看支持特性。
## 结果怎样解释
- 自动协商为 h2：客户端与服务端在该路径上完成了 HTTP/2 协商。
- 强制 HTTP/2 失败、HTTP/1.1 成功：继续比较直连和其他节点，检查中间代理能力与目标站点配置。
- 所有路径都只显示 HTTP/1.1：目标站或本机 curl 能力也可能是原因。
- 浏览器与 curl 不同：它们的协议栈、连接复用和缓存可能不同。
HTTP/2 经 TLS 通常仍运行在 TCP 上；看到 h2 不等于 HTTP/3 或 QUIC。测评时应把 ALPN 结果与连接耗时、失败率和真实任务分开记录。
## 验收清单
固定目标、设备、网络和时间窗口，对直连与候选节点各测数次；记录协议版本和请求是否成功。机场推荐结论应说明测试条件，不把“显示 h2”写成绝对性能优势。
来源：[RFC 7301：TLS ALPN 扩展](https://datatracker.ietf.org/doc/html/rfc7301)、[curl 命令行手册](https://curl.se/docs/manpage.html)。
解释TLS握手中的ALPN如何选择h2或HTTP/1.1，并用curl在固定目标下验证协议协商结果。
# 同一 IP 为什么返回不同证书？SNI 与 Host 的区别
一个 IP 地址上可以托管多个 HTTPS 网站。浏览器访问不同域名时，虽然可能连到同一个 IP，服务器仍能返回对应站点的证书和内容。这依靠的是不同协议阶段里的两个名称：TLS 握手阶段的 SNI，以及 HTTP 请求里的 Host（HTTP/2、HTTP/3 中对应 `:authority`）。
理解这一区别，对机场节点排障很实用：证书错误通常发生在 HTTP 请求发送之前，单纯改 Host 请求头往往修不好 SNI 或证书校验问题。
## 请求实际经过哪些步骤
1. 客户端解析 URL 中的域名，得到 IP。
2. 与目标 IP 建立 TCP 或 QUIC 连接。
3. TLS ClientHello 通过 SNI 告诉服务器希望访问的主机名。
4. 服务器据此选择证书，客户端核验证书名称。
5. TLS 成功后，客户端才发送带 Host 或 `:authority` 的 HTTP 请求。
RFC 6066 规定了 TLS `server_name` 扩展。它解决的是一个服务器地址承载多个虚拟主机时，服务器在握手阶段如何选择合适凭据的问题。
## 用 curl 做安全的单次验证
如果你有权测试某个网站，并已知它当前使用的服务器 IP，可以执行：
```bash
curl -v --resolve example.com:443:203.0.113.10 https://example.com/
```
把域名和示例 IP 换成真实测试目标。`--resolve` 临时把指定主机与端口映射到该地址，同时 URL 仍保留原域名，因此 SNI、证书校验和 HTTP 主机名保持一致。该设置只作用于这一条命令，不会改系统 hosts。
不要用 `-k` 或 `--insecure` 绕过证书错误作为“修复”。那只会跳过重要校验，无法证明代理路径正常。
## 常见误判
- **只在请求中添加 `Host:`。** TLS 已在 HTTP 之前完成，证书选择可能早已错误。
- **直接访问 `https://IP/`。** URL 主机名变成 IP，SNI 和证书校验目标都会变化，结果不能等同于访问原域名。
- **看到同一 IP 就认为同一网站。** CDN、反向代理和共享主机都可能让多个域名复用地址。
- **换机场节点后证书异常就认定节点劫持。** 还应核对系统时间、目标域名、客户端日志和直连对照，避免越过证据下结论。
## 验收思路
在同一设备上分别做直连、正常代理和另一个节点三次请求，保持 URL 不变，记录解析地址、TLS 证书名称、HTTP 状态与时间。如果只有某一节点在 TLS 阶段失败，证据才开始指向该路径；如果直连同样失败，应先检查目标站点或本机环境。
机场推荐或协议测评不应只写“能打开”。把 DNS、连接、SNI、证书和 HTTP 响应分开记录，结论更可复核。
可核验来源：[RFC 6066：TLS 扩展中的 Server Name Indication](https://datatracker.ietf.org/doc/html/rfc6066)、[curl `--resolve` 官方说明](https://curl.se/docs/manpage.html)。
拆解DNS、连接、TLS SNI、证书校验和HTTP Host的先后关系，避免用改请求头误修证书问题。
排查机场连接时，经常需要回答一个问题：失败来自 DNS 解析，还是连接到某个地址后的 TLS/HTTP 阶段？直接修改系统 hosts 会影响整台设备，也容易忘记恢复。curl 提供了两种只作用于当前命令的办法：`--resolve` 和 `--connect-to`。
## `--resolve`：为主机和端口临时指定地址
示意命令如下：
```text
curl --resolve example.com:443:203.0.113.10 https://example.com/
```
其中 `example.com` 和地址只是文档示例，实际测试必须换成你有权访问的目标。`--resolve` 相当于为“主机名 + 端口”提供一条临时解析记录。请求 URL、HTTP Host、TLS SNI 和证书校验仍以 `example.com` 为准，只改变本次连接使用的地址。
这适合比较“正常 DNS 得到的地址”和“已知候选地址”是否表现不同。测试结束后无需改回系统 DNS，因为规则只存在于这一条 curl 命令里。
## `--connect-to`：只替换网络连接目的地
示意命令：
```text
curl --connect-to example.com:443:backend.example.net:8443 https://example.com/
```
curl 官方手册说明，`--connect-to` 只改变建立网络连接时使用的主机和端口，不改变 TLS 使用的服务器名称，也不改变应用层请求中的原始主机。它适合在前端域名保持不变时，验证另一个后端入口。
## 两者不要混为一谈
- 已经知道目标 IP，想绕过本次 DNS 结果：优先考虑 `--resolve`。
- 想把连接导向另一台主机或另一个端口，同时保留原始 URL 语义：使用 `--connect-to`。
- 只是想看代理是否工作：先用明确的 `--proxy` 参数和普通 URL，不必加入这两个选项。
如果目标证书并不覆盖原始域名，curl 应当报证书错误。不要用 `-k` 或关闭校验来“修好”它；证书不匹配本身就是重要证据。
## 放进机场排障流程
先在直连状态执行普通请求，再在机场客户端提供的代理入口下执行同一个请求。只有确认普通请求失败点后，才加入 `--resolve` 或 `--connect-to` 做单变量对照。每次记录退出码、连接地址、HTTP 状态和总耗时，不要把含账号、Cookie、订阅密钥的完整命令发到公开场合。
验收时应看到：临时映射只影响当前命令；URL 主机名和证书校验没有被偷偷替换；去掉选项后行为恢复。这样才能把 DNS、网络连接与 TLS 三层分开，而不是把所有错误都归因于机场协议。
## 参考资料
- [curl 命令行手册：--resolve 与 --connect-to](https://curl.se/docs/manpage.html)
- [curl：HTTP 请求脚本指南](https://curl.se/docs/httpscripting.html)
用curl临时指定解析或连接目的地，把DNS、网络连接与TLS校验分开验证，不修改整机hosts。
在浏览器或系统里填写 HTTP 代理后，访问 HTTPS 网站并不是把加密网页内容直接交给代理改写。常见做法是先向代理发送 `CONNECT` 请求，请它建立到目标主机和端口的 TCP 隧道，再由客户端与目标站点完成 TLS 握手。
## CONNECT 请求解决什么问题
[RFC 9110 的 CONNECT 章节](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6)规定，客户端用请求目标中的主机名和端口，请代理建立隧道。代理返回 2xx 后，后续数据进入盲转发阶段；客户端发送的 TLS 握手和加密内容通过这条隧道传输。
因此，“HTTP 代理端口”描述的是客户端如何与本地或上游代理交互，不等于目标 HTTPS 网站退化成明文 HTTP。是否安全仍取决于客户端对目标证书的校验，以及中间是否存在用户明确安装并信任的解密证书。
## 为什么错误常出现在 TLS 之前
访问 HTTPS 网站通常经历：解析代理地址、连接代理、发送 CONNECT、代理连接目标、建立隧道、执行 TLS 握手、发送 HTTP 请求。任一阶段失败，表面上都可能只显示“代理连接失败”。
常见区分方法：
1. 连接代理端口就被拒绝，先查本地客户端是否监听、端口类型是否填对。
2. 收到 407，表示代理要求认证，应核对代理凭据，而不是网站账号。
3. CONNECT 返回非 2xx，查看代理响应与目标端口限制。
4. 隧道成功后出现证书错误，继续核对系统时间、目标主机名和证书链。
## 用 curl 观察隧道阶段
在确认本地 HTTP 代理端口后，可用详细输出观察连接流程。不要在要分享的截图中暴露代理用户名、密码、订阅地址或令牌。
```powershell
curl.exe --verbose --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com/
```
输出中若出现 `CONNECT example.com:443` 与成功的 2xx 响应，说明隧道建立阶段通过；之后的 TLS 和目标响应仍需分别判断。`--head`只请求响应头，不代表所有网站都支持，也不能代替实际业务测试。
## 端口名称不能代替实际验证
许多机场客户端同时提供 HTTP、SOCKS5 和 mixed 端口。把 SOCKS5 端口误填成 HTTP 代理，客户端与代理的首个报文格式就不匹配。反过来也一样。应以客户端界面或配置中的实际端口类型为准。
CONNECT 解释了 HTTPS 经过 HTTP 代理时的基础通道，但不直接证明流量最终走哪个机场节点、DNS 在哪里解析或 UDP 是否受支持。要判断这些问题，还需结合客户端规则、连接日志与实际出口做独立验收。
解释HTTP代理访问HTTPS时的CONNECT隧道、TLS握手与常见失败阶段，并用curl做最小观察。
配置机场客户端的 SOCKS 入口时，你可能见过 `socks5://` 和 `socks5h://`。在 curl 中，它们最直接的区别是目标主机名由谁解析；多出来的 `h` 并不表示一种更快的机场协议，也不是加密强度等级。
## 两种写法分别做什么
[curl 官方手册](https://curl.se/docs/manpage.html)规定，`--socks5` 使用本地解析目标主机名，`--socks5-hostname` 则把目标主机名交给 SOCKS5 代理处理。代理 URL 前缀 `socks5://` 与 `socks5h://` 分别对应这两种方式。
这里的“代理处理”指 curl 连接的那个 SOCKS5 服务端。如果它是电脑上的机场客户端，后续如何选择 DNS、如何分流，还取决于该客户端的配置。不能仅凭 `h` 就断言最终查询一定发生在远端节点所在国家。
## 先确认测试前提
核对客户端实际启用的 SOCKS 或混合端口，保持节点、分流规则和接入网络不变。下面用 `7891` 作示例；请替换为自己的端口。`example.com` 也是示例目标，正式对照应使用你有权访问且出现问题的完整域名。
Windows 可显式调用 `curl.exe`，其他系统通常使用 `curl`。先查看已安装版本的帮助，确认它支持这些参数。不要把订阅链接、账号口令或带令牌的地址放进要公开分享的命令。
## 只改变解析方式的对照命令
```text
curl.exe --noproxy "" --proxy socks5://127.0.0.1:7891 --connect-timeout 10 --max-time 20 --head https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:7891 --connect-timeout 10 --max-time 20 --head https://example.com/
```
两条命令都指定同一个本地入口，并清空本次请求的代理绕过列表。连接和总时长上限仅用于避免一直等待，不是判断网络是否合格的门槛。示例使用 HEAD 请求，只取响应头；若目标不接受 HEAD，可改用相同方式的普通 GET 再比较。
参数作用和本机支持情况以 [curl 手册](https://curl.se/docs/manpage.html)为准，示例不是针对任何机场的实测结论。
## 如何读结果
| 观察 | 下一步 |
| --- | --- |
| 本地解析失败，交给代理后成功 | 记录目标域名，检查本地解析路径与客户端DNS策略 |
| 两种方式都连接不到本地端口 | 先查客户端运行状态与端口，不急着修改DNS |
| 两种方式都成功，但浏览器失败 | 比较浏览器代理来源、扩展与实际访问目标 |
| 返回401、403、405等HTTP状态 | 已取得应用层响应，继续按网站权限或请求方法分析 |
只有第一种现象支持“解析路径差异值得继续查”的判断；它仍不能独立确定是哪一台 DNS 服务器有问题。
## 这不是完整的DNS隐私测试
代理服务器本身的地址、浏览器的安全 DNS、系统其他应用和 TUN 接管范围，可能使用不同路径。[curl URL 语法说明](https://curl.se/docs/url-syntax.html)也区分代理地址与目标地址的含义。因此，两条命令成功不等于整台电脑所有 DNS 都经过代理。
在机场推荐和日常排障中，把结论写成“同一目标在两种解析方式下的结果”，再附时间、端口类型与脱敏日志，才便于复现。一次对照解决一个问题，不需要同时替换节点、DNS和浏览器。
同一个SOCKS代理仅改一个字母就出现不同结果？理解curl的本地解析与代理解析，做受控对照，并明确结果不能证明哪些事情。
应用要求填写 HTTP 或 SOCKS5 代理，而机场订阅里写的是另一种协议，这通常不是冲突。前者描述应用怎样连接本地客户端，后者描述客户端怎样连接远端节点。把两段连接分开，很多“端口填了却不能用”的问题就容易检查。
## 先画清楚两段连接
常见使用方式可以简化为：
**浏览器或应用 → 本机代理入口 → 客户端内核 → 机场节点 → 目标服务。**
本地入口的协议类型和端口，应从当前正在运行的客户端读取；不能把远端节点端口、管理面板端口或订阅网址填进应用的代理栏。示例教程里的数字也不是所有客户端的通用默认值。
本文讨论普通应用的显式代理配置。TUN 接管属于另一种路径，不能仅凭应用未填写代理，就判断流量一定没有进入客户端。
## 三种名称分别表示什么
| 名称 | 用来判断什么 | 不能据此保证什么 |
| --- | --- | --- |
| HTTP 代理入口 | 应用按HTTP代理方式发送请求 | 不保证任意应用的UDP都被代理 |
| SOCKS5入口 | 应用与客户端使用SOCKS5交互 | 不保证软件已实现或启用UDP转发 |
| 混合端口 | 同一入口可接受HTTP与SOCKS连接 | 不等于多条线路叠加或速度翻倍 |
RFC 9110 中的 CONNECT 用于建立隧道，成功后双向转发数据；HTTPS 请求可以经这样的隧道建立到目标的 TLS 连接。[CONNECT 定义](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6)
SOCKS5 标准分别定义 CONNECT 与 UDP ASSOCIATE，后者用于建立 UDP 转发关联，并依赖相关 TCP 控制连接的生命周期。标准具有这项能力，不代表任意应用、客户端和节点组合都已支持。[RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.txt)
以 mihomo 为例，其文档分别列出 HTTP、SOCKS 和混合代理端口；混合端口接受 HTTP 与 SOCKS 请求。实际选用时仍需按应用提供的代理类型填写。[mihomo 代理端口说明](https://wiki.metacubex.one/config/inbound/port/)
## 怎样给一个应用填写代理
1. 在客户端确认当前运行状态和本地监听地址、端口、协议。
2. 查看目标应用提供哪些代理类型，选择双方都支持的一项。
3. 同机应用使用客户端实际提供的回环地址与端口；另一台设备不能直接照搬本机地址。
4. 保存后只发起一次小请求，核对客户端连接记录中是否出现该应用或目标。
5. 同时记录成功现象或报错原文，再决定是否更换类型。
不要同时更换节点、DNS、应用代理和系统代理。先保持节点与目标不变，才容易看出修改入口是否有效。应用没有提供某种代理类型时，不能仅靠把类型名称写进地址栏补上支持。
## 网页成功为什么不能证明UDP成功
可以打开HTTPS网页，只能说明该次请求走通。若你真正需要的是语音、特定游戏或其他使用UDP的功能，应测试那个功能本身，并在客户端可见记录中确认相关流量。
建议把验收拆成两行：“目标网页请求完成”和“目标UDP功能完成”。后一项没测过就写未测试。即使某项功能正常，也不要扩大成全部UDP应用都兼容。
遇到网页能用而另一个应用失败，先核对该应用是否真的使用了填写的代理设置，以及它对UDP代理的支持情况，再检查客户端和远端路径。盲目更改端口，无法替代这几层确认。
## 两个容易混淆的安全边界
**本地HTTP入口不等于目标网页明文。** 目标是否使用HTTPS、连接怎样经过本地入口、远端节点采用什么传输，属于不同问题。不要只看客户端界面的“HTTP”字样，就给整条链路作安全结论。
**开放局域网访问不是填写端口的必要步骤。** 同机使用先保持现有监听范围。如果确实需要其他设备接入，再单独规划监听地址、访问限制和认证；不要为解决单机连接问题随手对外开放入口。
最后保留一条简短记录：应用、代理类型、本地入口、实际出站、目标结果。能够说明某条连接怎样成功，才是选择端口类型的有效依据。
本地代理端口是应用连接客户端的入口，不等于机场节点协议。区分HTTP CONNECT、SOCKS5与混合端口，再按应用能力验证TCP和UDP。
开启机场代理后，网页访问正常，但开发者工具显示的协议是h2，而不是h3。这并不足以说明节点坏了，也不足以证明UDP正常。一次网页访问只说明那次请求选择的路径取得了相应结果。
要判断HTTP/3为什么没有出现，先把“网页协议”“代理的传输协议”和“UDP是否按预期转发”分开。本文给出的是诊断方法，没有测试或排名任何机场。
## 1. HTTP/3、QUIC和UDP分别处于哪一层
HTTP/3把HTTP语义映射到QUIC之上。QUIC的数据包由UDP数据报承载，同时由QUIC提供连接、流、可靠传输与拥塞控制等机制。因此，“基于UDP”不等于应用得到的是没有可靠性保障的文件传输。[RFC 9000：QUIC概述](https://www.rfc-editor.org/rfc/rfc9000.html#section-1)
HTTP/3规范同时考虑了连接失败：例如UDP被阻断导致QUIC无法建立时，客户端应尝试使用基于TCP的HTTP版本。这里描述的是协议建议；实际什么时候尝试、如何回退，还取决于具体客户端及网络状态。[RFC 9114：HTTP/3连接建立](https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1)
所以，网站继续打开并不矛盾。它可能走了可用的HTTP/2或HTTP/1.1路径。相反，看到h3也只证明对应连接使用了HTTP/3，不能证明所有UDP应用都可用。
## 2. 先看真实请求，再看宣传文字
以Chrome为例，打开开发者工具的Network面板，在请求表头菜单中显示Protocol列。重新加载待测页面，查看实际网络请求的协议值；官方说明中，h2对应HTTP/2，h3对应HTTP/3。[Chrome DevTools：Network功能参考](https://developer.chrome.com/docs/devtools/network/reference)
观察时记录主文档和关键资源，不要只挑一行符合预期的结果。一个页面可能从多个域名加载内容，不同资源使用不同协议并不奇怪。优先选择自己有权访问、且能确认支持HTTP/3的目标；如果目标能力未知，结果就应记为“目标支持情况未知”。
若请求来自缓存，先确认正在观察的确实是一次网络传输。不要把没有发生新连接的页面刷新作为节点测试结果，也不要公开分享含Cookie或令牌的完整网络日志。
## 3. 写下自己到底要验证什么
把测试目标写成可观察的问题，例如：
> 在这台电脑、这个浏览器和这个网站上，开启当前代理配置后，是否能建立HTTP/3请求，并且该请求按预期进入指定代理出站？
这个问题有两个条件：浏览器的请求协议，以及代理路径。仅满足一个，不能代替另一个。
如果你真正需要的是语音、游戏或其他UDP应用，应该直接验收对应应用的真实任务。HTTP/3页面测试只能作为补充证据，不能把网页成功概括成“UDP全支持”。
## 4. 一次只改变一个变量
可按下面的记录表进行小规模对照。直连测试只选择当前网络允许正常访问的目标；如果直连本来就无法访问，直接标记“不具备对照条件”。
| 条件 | 网页结果 | 请求协议 | 客户端路径证据 |
| --- | --- | --- | --- |
| 同网络、不经过代理的可用对照 | 成功或具体错误 | 实际读数 | 不适用或预期直连 |
| 同网络、当前代理配置 | 成功或具体错误 | 实际读数 | 命中规则与出站 |
| 同配置、另一个已有节点 | 成功或具体错误 | 实际读数 | 对应出站 |
| 同设备、另一个可信网络 | 成功或具体错误 | 实际读数 | 对应出站 |
每一轮都记录浏览器、客户端版本、目标和时间。改变节点后重新发起请求，并注意旧连接仍可能被复用；不要把切换按钮的时刻当作网络路径已经切换的证据。
## 5. 将浏览器结果与代理日志对应
在同一时间窗口查找目标域名、连接类型、匹配规则和实际出站。如果客户端只提供有限日志，就如实记录缺少的证据，不必为了“证明支持”输出一个确定结论。
- **h3出现，且日志表明请求走了预期路径**：可以记录本次目标的HTTP/3测试成功。
- **h2出现，网页正常**：记录当前请求使用HTTP/2；继续核对目标能力和网络条件。
- **浏览器有请求，客户端看不到对应记录**：先核对接管范围与独立应用配置，不能直接判为节点丢弃UDP。
- **更换网络后结果变化**：说明本地网络条件值得继续检查，但仍需排除测试目标或连接复用的差异。
代理客户端到节点所用的传输方式，和浏览器到目标网站的HTTP版本是不同层面的信息。即使节点名称含有QUIC或某个UDP协议，也不能单凭名字确定浏览器的全部流量会采用HTTP/3。
## 6. 验收标准应围绕实际用途
如果网页和日常任务稳定，只有h3没有出现，可以先记录兼容性差异，无需为了显示某个协议而大范围调整系统。若应用明确依赖某条UDP路径，则把该应用的成功条件、使用模式和可重复步骤交给服务方核实。
查看机场推荐或协议评测时，留意作者是否公开了测试目标、客户端模式和路径证据。清楚说明“某次请求回退到h2”，比把所有失败统称为“UDP被封”更有参考价值。
资料核对日期：2026年9月21日。
网页能打开但协议显示h2，不能直接断言机场不支持UDP。区分网站能力、浏览器选择、代理接管和回退行为，再做同目标对照。
IPv6 是否绕过机场代理，取决于应用怎样发起连接、客户端接管了哪些流量以及命中的出站规则。看到一个 IPv6 地址，或者检测页面显示“支持IPv6”，都不足以直接判断泄漏。需要核对的是：本应走代理的那次请求，实际经过了什么路径。
本文提供排查方法，不代表对任何机场或客户端做过隐私审计。以下示例以自己有权配置的设备与网络为前提；受管理的工作设备应按管理员要求检查。
## 先把三个不同环节分开
| 环节 | 需要回答的问题 | 单独观察的局限 |
| --- | --- | --- |
| DNS解析 | 目标有没有返回IPv4或IPv6地址 | 得到地址不等于已建立连接 |
| 本地接管和分流 | 该应用请求是否进入代理客户端，命中什么规则 | 开启某个模式不等于所有应用都被覆盖 |
| 实际出站 | 客户端最终走直连还是代理，目标看到什么出口 | 一个检测页面只代表对应请求 |
Cloudflare 的DNS资料说明，A记录保存IPv4地址，AAAA记录保存IPv6地址。本文只用这一区别来识别解析结果，不据此推断连接一定走哪一条路径。[Cloudflare：AAAA记录](https://www.cloudflare.com/learning/dns/dns-records/dns-aaaa-record/)
还要区分“电脑到代理服务器”和“代理服务器到目标网站”两段连接。它们不必使用相同的IP版本；代理连接采用IPv4，不能单独证明目标网站看到的出口也只能是IPv4。
## 第一步：先写清自己预期的分流结果
把需要检查的应用、目标网站和期望路径写下来。例如：某个浏览器访问某个测试目标应走指定代理组，局域网设备访问应保持直连。没有预期规则，看到不同出口后很难判断是正常分流还是意外绕行。
记录当前客户端和内核版本、代理模式、系统是否有其他VPN，以及是否启用了按应用排除。保留原配置，后续一次只改一个条件。不要一开始就同时关闭IPv6、替换DNS和切换节点。
## 第二步：对照同一次请求的连接记录
1. 在客户端打开连接列表或日志，清楚记录开始测试的时间。
2. 使用待检查的应用访问目标，避免换成另一个“刚好能用”的浏览器。
3. 查找匹配的目标主机或IP、命中规则、代理组和最终出站。
4. 如果记录中没有该请求，检查应用代理设置、排除列表及流量接管范围；同时确认日志本身是否完整。
“日志里没看到”是一条线索，不是完整证明。日志级别、记录保留时间、连接复用和测试目标选择都会影响你能看到的内容。无法对应到同一次连接时，应先补齐证据。
## 第三步：核对 IPv4 与 IPv6 是否被不同规则处理
有的配置会对不同地址族或目标网段分别匹配。sing-box 的路由规则文档列出了 `ip_version`，可匹配4或6；实际结果还取决于其他条件及规则顺序，不能看到这一个字段就确定整条连接的去向。[sing-box：路由规则](https://sing-box.sagernet.org/configuration/route/rule/)
检查当前加载的完整配置，而不只看订阅文件中某一行。界面覆盖设置、规则合并和应用排除可能改变最终行为。使用其他内核时，应查该内核的对应文档，不直接照搬字段。
如果同一目标的IPv4请求走代理、IPv6请求走直连，先确定这是否符合你写下的规则预期。需要修正时，依据当前内核版本调整相关规则，然后用原来的应用与目标重新验收。
## 第四步：TUN 模式也要检查覆盖范围
以sing-box为例，其TUN配置文档分别说明接口的IPv4/IPv6地址、自动路由、自定义路由与排除路由。这些是需要结合查看的设置，不能只凭“TUN已开启”就认为任何IPv6连接都已接管。[sing-box：TUN配置](https://sing-box.sagernet.org/configuration/inbound/tun/)
另外核对应用是否运行在容器、虚拟机、远程主机或另一个网络环境中。电脑本机的代理开关，不足以证明这些环境会自动采用相同路径。不要把TUN文档中的完整示例直接覆盖到现有配置；其中可能包含与你设备不适用的选项。
## 第五步：把出口检测与规则证据放在一起
使用能区分IPv4与IPv6结果的可信检测目标，记录时间与请求所在的应用，再与客户端出站记录对照。必要时用另一条已知网络复查，但分开保存结果。
| 观察结果 | 更稳妥的判断 |
| --- | --- |
| 只得到IPv4结果 | 本次测试没有确认IPv6路径，不能证明所有应用都不存在IPv6绕行 |
| 显示IPv6出口，日志命中预期代理 | 这次请求与预期一致，仍需检查其他目标与应用 |
| 应走代理的请求出现已确认的本地运营商出口 | 继续检查接管范围、直连规则和排除设置 |
| 出口地址归属信息与预期不同 | 先核验归属信息和实际出站，地理标签本身不是决定性证据 |
不要为了确认所谓“真实IP”而向陌生站点提交订阅、配置文件或账号。浏览器访问检测服务本身就会让该服务看到对应请求的出口信息，选择你愿意使用的服务即可。
## 关闭 IPv6 能不能作为修复？
临时改变IPv6相关条件后故障消失，只能说明变化与现象有关，还不能确定根因。长期处理应围绕明确的分流目标与客户端支持范围；恢复或调整配置后，要在重启应用、重连网络之后再次验证。
阅读机场推荐或测试新套餐时，也可以把“常用应用的IPv4与IPv6路径符合预期”加入验收记录。一次检测结果不构成完整隐私保证；清楚知道自己验证了哪些应用、目标和时段，才有助于之后定位变化。
资料核对日期：2026年9月20日。
看到 IPv6 地址不等于代理泄漏。区分 DNS 解析、流量接管与节点出站，按同应用、同目标核对规则和出口，判断是否符合自己的分流预期。
