必须用curl等实际发起HTTP/HTTPS请求的命令验证，观察“Connected to 127.0.0.1”和HTTP 200状态码双重信号，并辅以ipify.org或ipinfo.io比对出口IP，同时检查环境变量格式与代理进程是否运行。
Mac终端命令行是否真正走代理，不能靠浏览器表现判断，也不能用ping测试——因为ping不经过代理；必须用实际发起HTTP/HTTPS请求的命令验证，且要观察连接目标和返回内容双重信号。
用curl检查连接目标与响应状态
在终端中执行：curl -v https://httpbin.org/ip 2>&1 | grep "Connected to\|status"。
如果看到 Connected to 127.0.0.1 且返回 HTTP 状态码为 200 OK，说明请求已发往本地代理端口并成功获得响应。
若提示 Failed to connect to 127.0.0.1 port XXX: Connection refused，代表代理进程未运行或端口配置错误——此时应先检查 Clash/Surge 是否启动、系统代理是否开启、端口是否被占用。
对比IP地理位置判断出口是否变更
方法一：直接查出口IP
执行 curl -s https://api.ipify.org 记录当前IP；再开启代理后重新执行，两次结果不同即表示代理生效。
方法二：带地理信息的API更可靠
运行 curl -s https://ipinfo.io/country。未走代理时通常返回 CN，走代理后可能返回 US、JP 或 TW 等——该结果取决于你代理规则的实际出口节点。
注意：不要用 ip.cn 或某些国内检测站，它们会主动屏蔽代理IP或返回缓存结果，导致误判。
检查环境变量是否已加载
第一步：确认变量存在
输入 echo $http_proxy $https_proxy $all_proxy，至少有一个非空输出才算基础配置到位。
第二步：确认变量格式正确
常见错误是写成 http://127.0.0.1:7890 却用于 SOCKS5 场景——此时 curl 会静默失败。SOCKS5 必须用 socks5://127.0.0.1:7891 格式，且需确保 all_proxy 优先级高于 http_proxy。
第三步：快速复位验证
执行 unset http_proxy https_proxy all_proxy 后再运行 curl https://httpbin.org/ip，若返回本地真实IP，说明此前变量确实在起作用。
针对Git、npm等工具的专项验证
① 测试 Git 是否走代理：git ls-remote https://github.com/torvalds/linux | head -n1。成功返回类似 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx refs/heads/master 即通过。
② 测试 npm 是否走代理：npm config get proxy 查看配置值；再执行 npm view lodash version，能正常打印版本号才代表网络链路通达。
③ 若任一命令卡住超过15秒，立即中断（Ctrl+C），说明代理链路中断或目标域名被规则拦截——此时应回头检查代理工具的「允许局域网连接」和「系统代理」开关是否打开。
