一、配置文件的骨架骗了我
第一次直接用 Clash Verge 目录里的 config.yaml 起内核，日志显示一切正常，端口也起来了，可 GitHub 就是打不开。
原因是那份文件只是运行时骨架，节点列表是空的，所有流量都走了 DIRECT——等于没开代理。真正的节点在 profiles/<uid>.yaml 里，得按 profiles.yaml 的 current 去读，合并之后才能用。
教训：看到「启动成功」不等于「能用」，要验证出口。
二、加了代理参数，curl 还是直连
现象很迷惑：curl -x http://127.0.0.1:7897 https://github.com 要么 0.25 秒直接返回 000，要么卡到超时。而同一个代理访问 api.github.com 却正常。
查环境变量才发现，机器上有个 NO_PROXY，值里赫然写着 .github.com,.githubusercontent.com,codeload.github.com——它让 curl 主动绕过代理，专门去直连被墙的域名。改成只排除 localhost 之后一切正常；临时绕过则加 --noproxy ""。
教训：代理不通时先看 no_proxy，它比代理本身更隐蔽。
三、默认选中的节点是坏的
订阅里混着一批名字像「官网」「到期」「剩余 75.16 GB」的节点。它们和真实节点指向同一台服务器，但大多已经失效，而分组默认选中的恰恰是第一个。
解决分两步：生成配置时把这类信息节点排到分组末尾，启动后再对真实节点测一次延迟，自动切到最快的一个，并记住选择。
教训：默认值不等于可用值，能自动测就别信默认。
这三个坑的共同点
都不是「配置写错了」，而是「以为配好了，其实某一层悄悄绕开了」。所以每改完一次，我都会用独立的命令验证一次出口，而不是看日志说成功就收工。