开发者连接实测案例记录

实测案例：浏览器与终端访问同一 GitHub 域名时的路由隔离差异

测试目标：复现并记录为什么 Chrome 能正常打开 github.com，而 iTerm2 执行 git clone 却卡死的底层机制。

📋 实验环境与受控测量条件

测试目标端点：api.github.com / github.com

本地宽带环境：上海联通 500M 宽带

使用客户端版本：Surge Mac v5.8 / Clash Verge Rev

采样时间窗口：2026-11-06 16:30

单轮采样规则：同时发起浏览器 Fetch 与命令行 curl / git 操作各 5 次

💡 核心观察与事实发现

浏览器默认遵循操作系统「网络偏好设置」注入的 PAC/HTTP 代理，而终端（zsh/bash）进程除非显式注入 http_proxy 环境变量或开启底层 TUN 虚拟网卡，否则完全绕过图形代理直连公网。

详细数据分析与底层机制拆解

现象对比记录

- **浏览器端**：访问 `https://api.github.com/zen`，耗时 165ms 正常返回 HTTP 200，抓包显示请求流经本地 `127.0.0.1:7897` 代理端口。 - **命令行端 (未配置环境变量)**：执行 `curl -v https://api.github.com/zen`，Wireshark 捕获到 SYN 包直接发往 GitHub 公网 IP `20.205.243.166`，因遭遇跨国连接重置 (RST) 在 30 秒后报错 `Failed to connect`。 - **命令行端 (配置 TUN 模式)**：开启 Clash TUN 模式后，虚拟网卡劫持全局流量，命令行无需任何配置直接秒级返回。

→ 编辑部基于该实验的落地建议

开发人员推荐优先使用具备 TUN 虚拟网卡模式的客户端（如 Clash Verge Rev 带 Service 模式或 Surge Enhanced Mode），避免为不同终端工具逐一排查环境变量。

如何自行复核本篇实验数据？

科学的精髓在于「可复核与可证伪」。任何读者均可在自己的本地网络环境中，复现本篇场景笔记的测量过程：

打开本站「我的连接对照」工具；
目标端点选择为本实验相同的受控服务地址（api.github.com / github.com）；
单轮采样样本数设定为 15~20 次，确保中位数与四分位距（IQR）具有统计置信度；
对比记录导出的 JSON 结构化数据，若您的观测与本篇结论有较大偏差，欢迎通过工单向编辑部提交原始抓包日志。