程序员选机场：GitHub、文档与命令行代理要看哪几栏

程序员机场怎么选，不能照搬普通用户的思路。普通用户开了代理，打开网页能用就算成功；而开发者用机场的场景要复杂得多：浏览器、终端、包管理器、容器、IDE 的插件，每一个都有自己的网络出口，设置不到位，就会出现“网页能开，git 却卡死”这种让人抓狂的情况。这篇按开发者的使用习惯，把该看的资料栏位、该做的设置和该用的验证方法讲清楚。

程序员机场要看的五栏里，哪两栏最关键

爱梯子每份档案都分五栏：价格、线路、协议、节点地区、客户端。对开发者来说，重要程度并不一样：

协议和客户端这两栏如果资料是空的，就是你下单前要问清楚的第一件事：订阅支持哪些格式，能不能导入你手里习惯用的客户端。资料里写得越具体，后面踩坑的概率越低。想了解不同协议的差别，读 代理协议怎么选。

开发者的“代理”不只是浏览器：三条路径

要想把事情搞明白，先搞清楚开发者的网络请求走哪几条路。大致有三条，每条路径用的代理设置不同：

三条路径是相互独立的。开了系统代理，浏览器可能没问题，但终端不一定生效，这是最常见的误会。遇到这种症状，先读 开了系统代理没反应，把原理搞清楚比到处试要快。

命令行代理怎么设：从最轻量的办法开始

命令行工具走代理，最轻量的办法是设置环境变量。大多数命令行程序会读取 http_proxy、https_proxy 或 all_proxy，把它们指向客户端提供的本地端口即可。示例如下，端口以你所用客户端设置页里显示的为准，不要照抄：

  # 仅对当前终端会话生效，端口请换成客户端里显示的本地端口
export https_proxy=http://127.0.0.1:端口
export http_proxy=http://127.0.0.1:端口
  # 不想走代理的地址，用 no_proxy 排除
export no_proxy=localhost,127.0.0.1

git 也可以单独配置，只对需要的仓库生效；包管理器通常有各自的代理配置项，具体写法看对应工具的文档。容器则要区分“构建时”和“运行时”，两者的代理设置位置不同。原则只有一条：先用最小范围的设置解决问题，需要时再扩大，别一上来就全局改。

规则分流：让国内镜像和内网直连

开发者常有一个矛盾：要访问国外的代码托管平台，又要用国内的镜像源和公司内网。如果所有流量都走代理，国内镜像反而变慢，公司内网甚至访问不了。

解决办法是规则分流：把国内的域名、本地地址和公司内网段设为直连，只把需要的流量交给代理。规则怎么写、优先级怎么排，读 规则分流是什么；常用规则模式的区别，见上手手册里的相关篇目。分流配得好，既省流量又少出怪问题，对开发者的价值比单纯换更快的节点要大。

TUN 模式：什么时候用，什么时候不用

TUN 模式会创建一个虚拟网卡，接管系统里的网络流量，包括那些不遵守系统代理设置的程序，所以经常被开发者拿来“一劳永逸”地解决终端和容器的代理问题。它的好处和代价都很明确：

• 好处：不用逐个程序设置，覆盖面广。
• 代价：需要更高的权限；可能与其他 VPN、安全软件或虚拟化网络冲突；排错时多了一层要考虑的东西。

我们的建议是：先用环境变量和分应用设置解决具体问题，确实需要全局接管时再开 TUN，并且要知道怎么关掉它。想了解原理，读 TUN 模式是什么意思。

怎么验证 git clone 真的走了代理

设置完成之后，不要凭感觉判断，用命令验证。下面是一套简单的核对办法：

1. 在设置好环境变量的终端里，用 curl 请求一个返回你出口信息的地址，看看返回的地区是不是代理节点所在的地区。
2. 对比同一个仓库在开启和关闭代理时的 clone 耗时，注意要选同一个时段。
3. 查看客户端的连接日志，看有没有对应的请求经过，这是最直接的证据。
4. 如果设置了规则分流，再确认国内镜像的请求是直连，没有走代理。

记录下每次验证的结果，以后换机场、换客户端时，同样的方法可以直接复用。想针对 GitHub 打不开或很慢的情况做排查，读 GitHub 打不开或很慢怎么办。

内核与客户端：程序员机场要接得上你的工具链

很多开发者喜欢折腾内核，但从使用角度，更重要的是客户端是否稳定、是否支持你需要的协议和规则语法。现在说的 Clash 多指 Mihomo 内核及基于它的图形客户端；另有基于其他内核的客户端，协议覆盖和配置方式各有不同。了解内核之间的关系，读 Mihomo 是什么。

选择时有一条朴素的原则：优先选你已经熟悉、文档齐全的客户端，再看订阅格式是否匹配。折腾内核的乐趣和开发工作的效率，最好分开。

开发场景下，稳定性要看什么

开发者对稳定的要求，和看视频的人不同。几个值得单独留意的场景：

• 长时间的大仓库 clone 和依赖下载：连接中途断掉就要重来，所以对连续性要求高。
• 容器镜像拉取：体积大、层数多，对持续吞吐敏感。
• 远程开发和 SSH：对延迟和抖动敏感，断线会打断工作流。

这些场景的表现没法从资料里读出来，只能自己试。建议用最短周期，在工作日白天和晚上各跑几次真实任务，把耗时记下来。

程序员最容易踩的几个坑

• 只开了系统代理就以为终端也生效，结果 git 和包管理器仍然直连。
• 全局开 TUN 之后，本地的开发服务器、局域网设备访问异常，却不知道是代理造成的。
• 规则没配，国内镜像也走了代理，既慢又耗流量。
• 订阅链接贴进了公共仓库或聊天群，等于把账号凭证送人。
• 在公司电脑上擅自装客户端，违反了信息安全规定。

对着这五条自查一遍，大多数开发场景的网络问题都能提前避开。

适合怎么选，不适合怎么选

适合的做法：先看协议和客户端两栏，再用月付试用，用环境变量加规则分流解决命令行问题，用命令验证每一步。选程序员机场，核心就是把“能不能接上我的工具链”当作第一条标准。

不适合的做法：只看速度截图下单，拿浏览器能开当作全部验证，或者一上来就全局开 TUN、规则也不看。

接下来做什么

先用 选机场向导 按用途和预算筛出候选，把协议与客户端两栏当作硬条件；再翻 机场推荐榜 读候选的档案；最后买最短周期，按本文的验证办法跑一遍自己的真实工作流，再决定要不要续。想深入 GitHub 场景，读 GitHub 代理怎么设置。