症状分诊闭环 标准 SOP 排查流程
为什么浏览器能访问，终端却一直超时：命令行与全局代理隔离排障
典型用户症状：浏览器刷 Google、GitHub 秒开，但在 macOS Terminal 或 Windows CMD/PowerShell 中执行 git clone、npm install 或 curl 时一直卡死并报错 Failed to connect / Connection timed out。
🔍 可能引发该症状的底层技术原因拆解
- 终端命令（git, curl, brew, npm 等）默认不读取操作系统的图形系统代理设置
- 客户端开启了系统代理（System Proxy），但没有开启虚拟网卡 TUN 模式
- 环境变量 http_proxy / https_proxy 端口配置错误或未生效
按步骤标准化诊断与自救流程 (SOP)
1 第 1 步：确认代理软件本地监听端口
查看代理客户端界面上的 Socks5 / HTTP 端口（Clash 默认为 7890 或 7897，v2rayN 默认为 10809）。
验证标准：记下准确的端口号。
2 第 2 步：临时为当前终端会话注入代理环境变量
在终端中粘贴执行： export http_proxy=http://127.0.0.1:7897 https_proxy=http://127.0.0.1:7897 (Windows PowerShell: $env:http_proxy="http://127.0.0.1:7897"; $env:https_proxy="http://127.0.0.1:7897")
验证标准：在终端执行 curl -I https://api.github.com/zen，若返回 HTTP 200 即证明生效。
3 第 3 步：或者一劳永逸开启 TUN 虚拟网卡模式
在 Clash Verge Rev 中安装 Service Mode 并打开「TUN 模式」，接管全系统所有进程的 TCP/UDP 流量。
验证标准：开启 TUN 模式后无需配置任何终端环境变量，所有命令行工具自动透明走代理。
💻 极客自检：常用终端排障命令行工具
Windows CMD / macOS Terminal 通用图形界面偶尔会有缓存欺骗，在终端直接发送原生报文是判定链路是否存活的最准确方式：
// 1. 验证经过本地代理的 HTTP 真实连通性 (以 Google 为例)
curl -Iv -x http://127.0.0.1:7890 https://www.google.com
// 2. 测试 DNS 解析是否被运营商劫持污染 (查询真实 IP)
nslookup www.youtube.com 223.5.5.5
// 3. 查看本地系统代理监听端口是否正常处于 LISTEN 状态
netstat -an | grep 7890
⚠️ 故障解决后的恢复默认配置提醒
若关闭代理软件后终端报错拒绝连接 (Connection Refused)，执行 unset http_proxy https_proxy 清除终端环境变量即可恢复原状。
终极硬件解决方案
查看 2026 专线大盘榜单 →
若确认是节点在晚高峰拥塞丢包？切换至企业级 IEPL 专线
绝大多数晚高峰频繁转圈与超时，根源在于廉价中转走的是民用公网海缆。物理内网专线不过公网墙，晚高峰丢包恒定 0.00%。