机场对比怎么做：Windows 代理链路与线路稳定性实测方法
简答：机场对比应分成两部分：先用 ping、tracert 或 pathping 记录本地直连基线，再通过 Mihomo 的 url-test 或本地混合端口运行 curl，测试真正经过所选节点的 HTTP 延迟、首字节时间、下载速度和连续成功率。比较时必须固定协议、节点地区、目标地址、设备、网络和时间段，不能把直连 ICMP 结果当成机场线路质量。
定义：机场对比，是在相同设备、网络、目标地址、客户端和时间条件下，对不同服务线路的代理链路延迟、丢包表现、首字节时间、持续连接稳定性及节点信息进行可复现比较。
先区分：直连测试不等于机场线路测试
机场对比最容易出现的错误，是直接在 Windows 命令提示符中执行 ping、tracert 或 pathping，然后把结果当成节点质量。Microsoft 文档说明，tracert 通过 ICMP 回显请求和递增 TTL 观察路径，pathping 也会向路径中的路由器发送多次回显请求并统计返回结果。它们默认测试的是当前系统到目标地址的网络路径，不会因为浏览器设置了系统代理，就自动改为经过 Mihomo 节点。可参考 Microsoft Learn 的 tracert 文档 与 Microsoft Learn 的 pathping 文档。
因此，直连测试的用途是建立本地网络基线，例如确认当前 Wi-Fi、宽带或运营商是否已经出现高延迟和丢包；真正比较节点时，还需要使用客户端自身的延迟测试，或让 HTTP 请求明确指向客户端的本地代理端口。
如果启用了 TUN 和 fake-ip，域名可能先被解析为 fake-ip 地址。Mihomo 文档将 enhanced-mode 分为 fake-ip 和 redir-host，并说明 fake-ip 使用单独的地址范围。因此，在 TUN 模式下直接对域名执行 ping，可能只测到虚拟地址或本机处理过程，不能用来判断远端节点延迟。具体配置应以客户端当前运行配置为准，可查看 Mihomo DNS 配置说明 与 Mihomo TUN 配置说明。
机场对比前先固定五个条件
横向比较前，建议先写一张测试记录表，避免不同条件之间互相误导。
- 固定客户端：使用同一台 Windows 电脑、同一版本客户端和同一套规则。比较过程中不要一边切换系统代理、一边切换 TUN，再把结果放到同一列。
- 固定节点范围：优先比较相同协议、相同地区或相近地区的节点。不同协议、不同地区的结果只能作为不同方案对比，不能简单归因于服务商。
- 固定目标地址：准备一个稳定的 HTTP 或 HTTPS 测试地址、一个实际办公服务地址，以及一个日常使用目标。目标不同，路由和响应时间也可能不同。
- 固定测试时间：至少记录白天、晚间和网络繁忙时段。晚高峰只测一次仍然不够，最好在多个日期重复。
- 固定测试动作：每个节点使用相同次数的请求、相同超时和相同下载文件。不要把一个节点测首字节时间，另一个节点只测测速峰值。
节点数量、订阅中显示的地区数量和倍率说明可以作为信息记录，但不能直接等同于速度、稳定性或可用性。倍率是否存在、如何计算、是否影响流量消耗，应以对应服务公开说明为准；查不到时应标记为“未核实”，不要自行推断。
第一步：用直连命令建立 Windows 基线
在关闭客户端代理或明确使用直连模式时，可以先建立本地网络基线。以下命令只用于观察本地到目标的 ICMP 路径，不用于比较节点本身。
ping -n 50 example.com：记录平均延迟、最高延迟和是否有请求超时。tracert /d example.com：查看本地网络到目标的大致路径。Microsoft 说明，某些路由器不会返回超时消息，出现星号不必然表示最终连接失败。pathping /n example.com：等待统计完成后观察各跳和链路的丢包结果。Microsoft 特别说明，中间路由器即使对发往自身的探测包丢包，也不一定影响它转发其他流量，因此需要结合后续节点和最终目标判断。
基线的作用是回答“本地网络是否已经异常”。如果未启用客户端时就存在明显丢包，之后所有节点都表现很差，优先检查 Wi-Fi、路由器、网卡、DNS、后台下载和运营商链路，而不是立刻把问题归因于某个节点。
第二步：用 Mihomo 的 url-test 比较节点响应
Mihomo 的 url-test 代理组可以对候选代理使用指定 URL 进行测试，并按照设定的间隔更新结果。官方示例包含 url、interval 和可选的 tolerance 字段，详情见 Mihomo url-test 配置说明。
如果客户端支持编辑或查看代理组配置，可以按以下思路设置，字段值仅作格式示例：
proxy-groups:
- name: "对比测试"
type: url-test
proxies:
- 节点A
- 节点B
- 节点C
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50实际操作时注意三点：第一，测试 URL 应保持不变，并确认目标可以正常返回；第二，interval 是自动复测间隔，不是一次测试的完整稳定性证明；第三，自动选择组适合发现响应较快的候选节点，但不能代替晚高峰、长连接和真实办公场景测试。
若要做公平横向比较，建议暂时手动选择单个节点，等待连接建立后再进行下一项 curl 测试。不要让一个节点处在自动选择组，另一个节点处在手动模式。
第三步：让 curl 明确经过本地代理端口
这是比较节点时最关键的一步。Mihomo 可以提供 HTTP、SOCKS 或 Mixed 入站端口；官方文档列出了 port、socks-port、mixed-port 等入口类型，具体端口要以当前配置和客户端界面显示为准，参考 Mihomo 入站配置说明。
假设客户端当前显示的混合端口是 7890，在 Windows PowerShell 或命令提示符中执行：
curl.exe -x http://127.0.0.1:7890 -o NUL -s -w "code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" --max-time 30 https://www.gstatic.com/generate_204curl 官方文档说明，-x 或 --proxy 用于指定代理，time_connect、time_starttransfer、time_total 和 speed_download 可以通过 --write-out 输出。相关字段可查看 curl 官方 man page。
如果使用的是 SOCKS 端口，可以将代理写成类似 socks5h://127.0.0.1:7891。其中端口只是示例，必须替换成客户端实际端口。socks5h 会让域名解析交给 SOCKS 代理处理；若使用 HTTP 或 Mixed 端口，则按客户端支持情况填写对应协议。
每个节点建议连续执行 10 至 20 次，记录 HTTP 状态码、连接时间、首字节时间、总耗时、下载速度和超时次数。完成一个节点后，手动切换到下一个节点，等待连接稳定，再重复完全相同的命令。这样测到的是“本地电脑经由当前选定节点访问目标的 HTTP 表现”，比直接 ping 域名更接近网页和办公应用的实际体验，但仍不等于所有应用的表现。
第四步：怎样观察丢包、晚高峰和长连接
普通 ping 不能穿过大多数代理链路，所以不能直接用 ping -t 证明某个节点有多少丢包。若你控制节点出口上的远程主机，或服务方提供了明确的远端诊断入口，才可以在远端执行持续探测；否则不要声称已经测得“节点出口丢包率”。
没有远端 shell 时，可以使用经过代理的重复 HTTP 请求，记录失败率和超时率，作为应用层稳定性指标。例如：
for /L %i in (1,1,20) do @curl.exe -x http://127.0.0.1:7890 -o NUL -s -w "%i code=%{http_code} total=%{time_total}\n" --max-time 20 https://www.gstatic.com/generate_204这不是链路层丢包测试，而是“通过当前代理节点完成目标请求的成功率”。如果请求超时，可能来自节点、目标服务、DNS、规则、TLS 握手或本地网络，必须结合客户端日志和其他节点复测。
晚高峰测试建议至少记录四项：连续请求成功率、首字节时间变化、长时间连接是否中断、切换节点后的恢复时间。视频会议或远程办公场景还应做一段真实任务测试，例如保持会议或远程协作连接一段时间，记录是否出现卡顿、重连和音视频中断。不要用一次短请求的低延迟，替代长连接稳定性结论。
第五步：同协议、同地区节点怎么横向比较
“机场对比”如果要得出相对可靠的结论，至少应建立两组比较：同一服务内的节点比较，以及不同服务之间的相近节点比较。
| 比较维度 | 建议做法 | 可得出的结论 | 不能直接得出的结论 |
|---|---|---|---|
| 协议 | 优先比较协议相同或配置目标相同的节点 | 观察节点路径和协议配置在当前网络下的表现 | 不能据此证明所有协议都一样快 |
| 地区 | 选择相同或相近地区，并记录节点名称与地区信息 | 比较相近路由条件下的响应差异 | 不能仅凭地区名称判断线路质量 |
| 晚高峰 | 在固定时间重复 curl 和真实任务测试 | 观察繁忙时段的波动、超时和长连接表现 | 不能据几次测试保证长期可用 |
| 订阅信息 | 记录节点数量、协议、地区、倍率说明和更新时间 | 了解配置范围与公开说明是否完整 | 不能把节点数量或倍率直接当成速度排名 |
| 客户端兼容 | 在同一 Windows 客户端中测试导入、规则、Mixed 端口和 TUN | 判断当前客户端配置是否能正常使用 | 不能推断其他系统和其他客户端一定相同 |
最终记录建议包括：测试日期、网络类型、客户端版本、模式、节点名称、协议、地区、目标地址、平均首字节时间、超时次数、下载速度、连续请求成功率和真实任务结果。没有原始条件的速度截图、排名和“全天稳定”说法，都不适合作为唯一依据。
常见结果异常与排查顺序
- curl 显示连接被拒绝：检查客户端是否运行、端口是否写对、Mixed 或 HTTP 入口是否开启，以及 Windows 防火墙是否拦截本地客户端。
- 浏览器能用但 curl 失败：确认浏览器是否走了 TUN，而 curl 是否明确指定了正确代理；两者可能不是同一种出站路径。
- TUN 开启后 ping 延迟异常低：检查域名是否解析到 fake-ip，避免把虚拟地址响应当成远端节点延迟。
- 某节点 HTTP 请求成功但办公应用失败：继续检查应用是否使用独立代理、UDP 是否需要支持、DNS 规则和 MTU 是否匹配。HTTP 成功不能证明所有协议和应用都正常。
- 晚高峰只有部分节点变慢：先固定目标地址和测试命令，重复记录多个时间点，再比较首字节时间、超时和长连接结果，不要只看某一次下载速度。
结论：机场对比要比较真实代理链路
可执行的机场对比流程应是：先关闭代理，用 ping、tracert 或 pathping 建立本地直连基线；再在 Mihomo 中固定节点、协议、地区和测试 URL；随后通过 url-test 观察候选节点响应，并使用 curl 的 --proxy 明确让请求经过本地代理端口；最后在白天、晚高峰和长连接场景下重复记录。
直连 ICMP 结果只能说明本地到目标的基础路径，不能替代经过代理的节点测试。TUN、系统代理、fake-ip、DNS、规则和 MTU 都可能改变结果，因此每次记录都应写清模式和配置。没有远端诊断权限时，不要把应用层请求失败率包装成节点出口的精确丢包率。
本文不对任何未提供可核验原始数据的具体服务作价格、状态、速度或排名判断。涉及订阅、节点说明和服务可用性时，应以对应服务的公开信息为准。
常见问题
机场对比时直接 ping 节点域名可以吗？
不建议把它当成节点质量结论。ping、tracert 和 pathping 默认使用系统网络路径，通常不会自动经过客户端代理；如果启用了 TUN 和 fake-ip，域名还可能解析到虚拟地址。应先用这些命令建立直连基线，再使用客户端 url-test 或通过本地代理端口运行 curl。
系统代理模式和 TUN 模式会影响测试结果吗？
会。系统代理通常只影响支持代理的应用，命令行工具是否经过代理取决于是否显式指定代理；TUN 会捕获更多系统流量，但 DNS、fake-ip、规则和 MTU 也会影响结果。比较前应记录当前模式，并保持所有节点使用同一种模式。
如何用 curl 测试真正经过节点的延迟？
先在客户端查看实际的 HTTP、SOCKS 或 Mixed 本地端口，再使用类似 <code>curl.exe -x http://127.0.0.1:7890/ ...</code> 的命令，并通过 <code>time_starttransfer</code>、<code>time_total</code> 和超时次数记录结果。端口号只是示例，必须替换为客户端当前配置。
没有远程服务器权限，能否测出节点出口丢包率？
不能精确测出链路层出口丢包率。没有远端 shell 或服务方提供的诊断工具时，可以通过代理重复 HTTP 请求记录超时和失败率，但这属于应用层稳定性指标，不能直接等同于 ICMP 丢包率。
机场对比应该看节点数量和倍率吗？
可以记录，但不能直接据此判断速度或稳定性。节点数量反映配置规模，倍率属于服务方的计费或流量说明，是否存在以及如何计算应以公开规则为准。真正横向比较仍应固定协议、地区、目标和时间，查看代理链路测试结果。
为什么一个节点白天很快，晚高峰却变慢？
可能与本地网络、目标服务、互联路径、节点负载或规则配置有关。应在相同目标和命令下跨多个时间段重复测试，比较首字节时间、超时、连续请求成功率和长连接表现，而不是只看一次测速峰值。