出网走 7890

这台机器出网走 127.0.0.1:7890。我写进本机约定，是因为同一类事故发生过太多次：开新终端，pip、git、模型下载全失败，我先怀疑网站挂了，再怀疑学校网，最后才想起代理没挂上。排查顺序反了，一上午就没了。课设前、下权重、clone 私有仓库，三次都是同一出。浏览器能开，终端不能开，人就去骂学校网。学校网那天往往没坏。坏的是新开的壳没读到 zshenv。读到了再骂网，才骂得值。

变量写在 zshenv，不在 zshrc

代理相关的环境变量在 ~/.zshenv，不在 .zshrc。zsh 启动时，很多非交互、非登录的场景会读 zshenv，不一定读 zshrc。我以前只改 .zshrc，结果 VS Code 终端有代理，agent 拉起的 shell 没有。同一台机器，两种网络世界。

表现很具体。浏览器能打开文档，终端里 git clone 卡住。或者反过来：终端能走代理，图形程序走直连，证书错误一串。我后来的习惯是：先 echo $https_proxy，再判断网站。空的就先补环境，不先重装工具。

有一次跑检测相关的依赖安装，日志写的是连接重置。我以为 PyPI 镜像坏了，换了两个源。源都没问题，是子进程没继承代理。变量放对文件，比再找一个镜像省事。

开新终端没有代理，会像网络坏了

macOS 上我经常同时开好几个终端。有的是自己敲的，有的是 Cursor 或脚本拉起来的。后者最容易「看起来没网」。pip 报错、git 报错、Hugging Face 拉模型报错，措辞都不提代理。人就会往防火墙、DNS、校园网认证上想。

我现在的排查顺序写死了。第一看环境变量。第二看 127.0.0.1:7890 这个端口自己的程序还在不在。第三才看远端。这个顺序救过我几次课设前的晚上。演示包要下依赖，网「断了」，其实是新开的面板没读到 zshenv。

学校实验室的机器和这台笔记本还不一样。实验室有时走系统代理，笔记本走本地端口。脚本里写死 7890，换机器就错。所以约定只约束这台机器。仓库文档里如果出现「请设置 7890」，那是我抄错地方了。

不要把端口写进给别人的文档

7890 是这台机器上代理软件的监听端口。别人的机器可能是 1080、7897，或者根本不用本地代理。我在项目 README 里写过一次「导出这几个变量就能出网」，同学按着做，端口对不上，反而多一层迷惑。

给以后的自己：仓库文档写「需要能访问外网」，不要写我的端口。个人笔记可以写端口，因为这是个人站。两者混在一个 md 里，发布之前要拆。

代理也有失败模式。端口开着，规则没开系统代理，终端变量有了，curl 仍走直连。我被这个坑过。检查方法很土：访问一个确定要走代理才打得开的地址，看返回是超时还是内容。土，但比猜强。

和 agent 约定绑在一起

本机给 Cursor、Claude Code 用的约定里，出网必须走本地代理这一条写得很靠前。原因简单：它们会自己跑安装命令。没代理时，失败日志很长，模型会总结成「依赖冲突」或「权限不足」。总结越像那么回事，我越容易跟着改无关的文件。

我要求它们先探测代理变量。没有就停，不要换源、不要改锁文件、不要对全局 pip install。全局安装一旦发生，后面的仓库更难讲清楚「这个环境到底属于谁」。

检测平台、智链前端、个人站，出网需求不一样。个人站 bundle exec jekyll serve 多数时候不需要外网。模型权重和 npm 包需要。把「这台机器出网走 7890」当成全局真理可以；把「所有命令都要先走代理」当成全局真理不行。命令自己会说它要不要网。

还没自动化的部分

我没有做开机自检脚本。端口挂了，我仍是先手动看一眼。挂系统代理的图形界面有时会自己退出，终端变量还在，流量已经不走隧道。这种半残状态最耗时间。

这篇只记录这台机器的事实。换端口、换软件、换 shell，句子都要改。在那之前，排查先看环境变量，再看网站。网站没错的时候，错的是我忘了 7890。

检测权重、npm 包、git 远程，失败日志很少写「你没挂代理」。它们写超时、重置、证书、权限。我顺着日志改过镜像、改过 token、改过仓库地址，都没改到点子上。后来我在本机约定里把代理探测放到很前，就是为了让下一轮的自己和 agent 少做那三轮废动作。废动作看起来像工作。工作完，网还是断的。