Clash Proxy Tools
ChatGPT、Codex 等 AI 工具已经成为了学习和科研离不开的资源，但是使用它们需要科学上网（我不会解释这个词）。为了后者我们需要代理工具。
本文系统性地介绍了代理工具以及其基本概念，工作流程。并且以 Clash 这一常见的代理工具为例对以上内容做了较深入的剖析。读完本文后，你应当就能理解你的代理工具并且熟练使用它，因此就能有更好的科学上网体验。
此外，最近代理节点被查得很严，所以对代理软件有更多的了解有助于你找到/自己添加更好的代理节点，或者起码能在科学上网体验糟糕时明白问题出在哪里（这样才能让 AI 去修）。
Clash Proxy Tools
前置知识：计算机网络
本文默认读者对计算机网络有基本了解，特别是知道 TCP/IP 层。如果需要补背景，可以先看：
下面先约定几个术语。
- 流量（traffic）：在本文中，流量泛指网络中被传输和处理的数据单元。根据讨论层次不同，它可以指 IP 包、TCP/UDP 段，或者应用层请求。若不特别说明，本文主要从 IP 包和 TCP/UDP 连接的角度讨论。
- 连接语义（flow semantics）：指从一条网络流中可以恢复出的关键信息，例如目标 IP、目标端口、传输层协议、应用层协议，域名等等。
- 公网中的中间路由器：指本机公网出口与远程服务器公网入口之间（我们假设本机和远程服务器处于两个局域网内，并通过公网连接），负责转发外层 IP 包的互联网路由器。对于 VPN 隧道来说，这些路由器通常只能看到外层 IP 头，例如“本机公网出口 → VPN 网关”，而看不到被封装和加密的内层目标地址。
- VPN 网关（VPN gateway）：指 VPN 隧道的远端终点。客户端把封装后的隧道流量发往 VPN 网关；VPN 网关解封装后，再把内层 IP 包转发到目标网络或公网目标。
- 代理（proxy）：代理是一种计算机网络中常用的抽象操作，指把“A 直接连接 B”改为“A 先连接 C，由 C 作为代理代替 A 连接 B”。代理可以出现在协议栈的不同层次，但日常所说的 HTTP proxy、SOCKS proxy、Clash / clash proxy 通常属于应用层代理。
- Clash / mihomo：日常所说的 “Clash” 泛指一类 clash 代理工具生态。这类工具通常由两部分组成：前端和后端。前端负责图形界面、配置管理、节点选择等交互；后端才是真正执行代理逻辑的核心。Clash 常用的后端是 mihomo，前端的实现很多，本文以 Clash Verge 为例。
- 类似 clash 的代理工具还包括 V2Ray / Xray、Shadowrocket 等。它们的具体协议、配置格式和实现细节不同，但基本工作模式相近：接收流量、解析连接语义、执行规则决策、重新出站。
- 因此，本文中若无特别说明，Clash、mihomo 等名称都作为泛称使用，指这一类代理工具，尤其是其中真正执行代理逻辑的后端程序。
- Clash TUN mode：clash 类型软件一般提供隧道模式（TUN mode，tunnel mode）和系统代理（system proxy）两种工作方式。后者比较简单，我们放在最后介绍。真正在功能上接近 VPN 的是隧道模式，因此本文中，除非特殊说明，否则介绍的都是隧道模式。
- TUN 接口：Clash TUN 会创建虚拟网卡来在路由表中捕获流量（见下文），因此，这些虚拟网卡（一般来说，同一时间只用一个）也被称为 TUN 接口。
- 代理节点：指作为代理的路由器/主机。如果代理要翻墙，那么代理节点都位于境外（包括香港）。代理节点通常要通过“订阅”来付费购买。
背景介绍：代理软件
通俗地讲，代理软件是一类用于翻墙的软件，关于什么是“翻墙”我就不解释了。我们通常说的代理软件其实包含很多组件：
- 代理软件本身，通常还分为
- 图形界面和命令行界面，称为客户端/前端/UI
- 一个运行在后台，真正处理流量和规则的程序，称为后端/内核。
- 代理软件的配置文件，描述代理节点、代理节点组、规则、DNS 等设置。
- 代理软件之外的东西：
- 代理节点：具体的远程代理服务器。它一定能被你（安装了代理软件）的本地电脑访问（否则你的代理软件就连接不上节点）；并且也一定能访问外网（否则你为何要用这个节点呢？）。节点信息（节点的连接方式，包括 ip，端口等）被记录在代理软件的配置文件里。一般来说节点的 ip 都是从机场付费购买的，毕竟没有谁会把自己的服务器免费给陌生人用。
- 订阅链接：用来下载（代理软件的）配置文件的链接。
- 机场：提供订阅和代理节点的服务商。由于代理节点经常是不稳定的，且经常被封，所以配置文件需要不断地更新（特别是更新其中的代理节点信息）。为此，现在的机场都把订阅实现为一个“下载链接”，用户可以从该订阅的链接中下载最新的代理文件。
用户使用代理软件的流程为：
- 安装一个代理软件；
- 从某个机场购买订阅链接，在代理软件的客户端中导入该订阅链接；
- 在客户端中选择一个节点，例如选择台湾节点；
- 然后根据需求使用系统代理或虚拟网卡（TUN）这两种代理方式之一。普通用户使用“系统代理”即可满足需求，这部分后面会讲。（如果是虚拟网卡（TUN）方式，那么所有程序都能走代理；如果是系统代理方式，那么浏览器和图形类app都能走代理，而终端程序通常不行。）
- 选择好代理方式后，浏览器、Telegram等程序就可以通过代理访问网络。
用图像理解：
flowchart TD
A[浏览器 / 其他应用]
B[系统代理或虚拟网卡]
C[本机代理软件的客户端]
D[本机代理软件的内核]
E[配置文件中的分流规则]
F{出站策略}
G[直连 DIRECT]
H[拒绝 REJECT]
I[某个代理节点]
J[目标网站]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G --> J
F --> H
F --> I --> J背景介绍：Clash
之前介绍了代理软件，而所有代理软件中最常用的就是（电脑端） Clash 和（手机端）ShadowRocket。本文就以 Clash 为例，对 Clash 进行详细介绍。并且其经验也可以迁移到 ShadowRocket 等软件。
前面说过，代理软件本身可以分为前端和后端，Clash 也不例外。Clash Verge、ClashX 等都是可用的前端；Mihomo、Xray 等是常用的后端。
本文使用的 Clash 是 Clash Verge 前端 + Mihomo 后端。前后端的实现差异对用户来说一般不可见，所以用 某前端/后端实现都不影响对 Clash 的理解。
代理软件的配置文件
代理软件不可能凭空知道某个服务器作为代理节点可以访问外网并将其作为代理节点；它也不知道用户对哪些网站的访问要走代理，哪些又不要。因此，用户需要提供一份配置文件让代理软件读取这些信息，而代理软件的行为也是由配置文件所决定的。
配置文件当然要从机场购买。准确地说，你需要从机场购买一份订阅链接，然后从这个链接中下载最新的配置文件。你可以每天刷新配置文件（也就是下载最新的配置文件）甚至刷新订阅（有的机场会不断更新订阅链接），确保你的配置文件和订阅是最新的。
在 Clash 中，配置文件也叫做 Profile，一个典型的配置文件通常包括：
mixed-port: 7890 |
这份配置的含义是：
- Clash 会监听本机的 7890 端口作为（所有流量的）入口端口，应用程序通过该端口连接 Clash
- Clash 有一个节点 “Japan A”；
- Clash 有一个代理组 PROXY，可以选择 Japan A 或 DIRECT；
- 访问 google.com 时交给 PROXY；
- 访问中国大陆 IP 时使用 DIRECT（也就是不走任何代理节点，直连）；
- 其他流量默认交给 PROXY。
下面我们来详细分析配置的每个部分。
1. 入口端口：应用程序连接 Clash 的入口
配置文件开头经常会看到：
port: 7890 |
这些端口是 Clash 在本机打开的代理入口。可以看到这里有三种代理入口，分别是：
port: 代理 HTTP（S）流量socks-port: 代理 SOCKS 流量mixed-port: 它是混合端口，一个端口能同时接受 HTTP proxy 和 SOCKS5 proxy 流量。
一般来说用户只需使用 mixed-port 即可，因为它能同时涵盖 port 和 socks-port 的处理范围。
入口端口表示两件事，我们以
socks-port: 7891 |
为例，这表示：
Clash 会在本机监听一个 SOCKS 代理端口：
127.0.0.1:7891
顾名思义，它能处理 SOCKS 协议的流量。
如果你想让app的某个请求使用 Clash 的代理，例如你想让 Chrome 浏览器对
www.chatgpt.com的请求使用代理，那么你可以让该请求通过这个被 Clash 监听的端口。请求会先被 Chrome 送入 Clash，再由 Clash 决定后续怎么走。
关于如何让一个请求走该端口，请参见下文的 系统代理和 TUN模式 的章节。
注意，入口端口是是“应用进入 Clash 的端口”，是 Clash 在本地启动的。因此你会看到表示本机的 IP 地址 127.0.0.1。后续流量会通过端口走具体的代理节点，这仍由规则和代理组决定
2. proxies：节点列表
proxies 是配置文件里的节点列表。每一个节点表示一个可以使用的远程代理服务器。
例如：
proxies: |
每个节点至少需要描述几类信息：
节点名称：name |
不同协议需要的字段不同。常见协议包括：
ss |
节点本身只表示“可以往哪里转发流量”。但是 Clash 不会自动使用某个节点，除非规则或代理组选择了它。
3. proxy-groups：代理组
我们经常不会使用某个固定节点，而是将一群节点组织起来称为一个集合，称为代理节点组，或简称代理组，Proxy Group。Clash 可以指定使用某个固定的代理节点组，并在运行时不断地测试节点组中每个节点的速度，动态切换到最快的那个节点。当然，你也可以固定使用节点组中的某个节点。
例如：
proxy-groups: |
这个配置创建了一个叫 PROXY 的代理组。它里面有三个选项：
Japan-01 |
其中 DIRECT 表示直连，不经过代理节点。
规则（见下文）通常不会直接指向某个具体节点，而是指向一个代理组。例如：
rules: |
这表示：
访问 google.com 时，交给 PROXY 这个代理组处理。 |
至于 PROXY 里面最终选择 Japan-01、US-01 还是 DIRECT，则取决于分流策略和用户选择。
4. 常见代理组类型
代理组自然是用户手动规定的，但是一般来说机场都会默认给你设置好一些代理组。
4.1 select：手动选择
- name: "PROXY" |
select 是最直观的类型。用户可以在客户端界面里手动选择当前使用哪个节点。
适合：
手动切换地区 |
4.2 url-test：自动测速选择
- name: "AUTO" |
url-test 会定期访问一个测试 URL，然后选择延迟较低的节点。
适合：
但是要注意：延迟低不等于带宽高，也不等于稳定性最好。
5. rules：规则列表
有了节点和节点组之后，Clash 就能让流量通过他们走代理了。但是，很多时候我们希望对“哪些流量走哪些代理甚至不走代理”这件事有更精细的控制。比如，我们知道中国的用户都能够直连（不走代理）百度和哔哩哔哩，但是无法直连 ChatGPT 和 Youtube。那中国用户肯定就希望：
- 对那些本来就能直连的网站直连（不走代理）。
- 对那些不能直连的网站走代理。
当然，这只是最普通的划分。有时候你可能想要用国外 IP 来访问国内网站（例如你想装成外国人），这个就看你的需求了。
总的来说，为了支持这种更精细的流量把控，或者说“分流”，Clash定义了一套基于规则的分流机制。规则就是订阅文件中的rules ，它决定了某个请求最终走哪个代理组或节点。
例如：
rules: |
可以按顺序理解为：
如果域名后缀是 google.com，走 PROXY； |
规则是从上到下匹配的。一旦匹配成功，就不会继续往下匹配。
6. 常见规则类型
6.1 DOMAIN-SUFFIX
- DOMAIN-SUFFIX,google.com,PROXY |
匹配某个域名后缀。
它可以匹配：
google.com |
6.2 DOMAIN
- DOMAIN,www.google.com,PROXY |
精确匹配某个域名。
它只匹配：
www.google.com |
不会自动匹配：
mail.google.com |
6.3 DOMAIN-KEYWORD
- DOMAIN-KEYWORD,google,PROXY |
只要域名里包含 google 就匹配。
它比较宽泛，容易误伤，所以要谨慎使用。
6.4 GEOIP
- GEOIP,CN,DIRECT |
根据目标 IP 所属地区匹配。
常见用法是：
中国大陆 IP 直连 |
不过它依赖 IP 数据库，且域名解析结果会影响匹配效果。
6.5 MATCH
- MATCH,PROXY |
MATCH 是兜底规则，表示前面都没匹配上时，使用这个策略。
通常放在规则列表最后。
如何修改配置文件？
这个问题看起来可笑，因为你当然可以直接修改那个配置文件（我们前面没有讲配置文件的位置，但这个信息你很容易查到，甚至在 Clash 客户端里都能查到。），它（一般来说）只是个 yaml 文件。
但是，前面说过，clash 等一众代理软件等配置文件是从机场给的订阅链接下载的，每次下载就会得到一份新的配置文件。因此，虽然你可以直接修改配置文件，但你对该文件的修改总是会随着新配置文件的下载而被覆盖。你当然可以每次把修改手动同步到新配置文件中，但 Clash 等代理软件提供了更快捷的方法。
以我用的 Clash Verge 客户端为例，它的“设置”中就提供了“全局扩展覆写配置”和“全局扩展脚本”两种修改配置的方式。
一般来说客户端里都会有这两个入口，实在不行的话你可以问 AI。
顾名思义，前者就是提供一个额外的不会被动态更新的配置文件，称为 merge 文件，你在里面写那些你想添加的内容（例如，你想添加对某网站的分流规则，因为你对现成的分流规则不满意），然后这个 merge 文件就会在 clash 读取配置时被 merge（合并，就是把两个配置文件拼起来）到原本的配置文件。
现在大家都用 ChatGPT，而我的机场给的配置文件恰好就没有指定对 openai（下属的各个网站）走代理，导致我总是因为直连 openai 而访问失败。所以我就手动修改 merge 文件来添加了对 openai 的分流规则。
而后者就是允许用户写一个脚本（对于 Clash Verge + Mihomo 来说是 javascript 脚本）来在 clash读取配置时动态更新该配置文件。
可见，写 merge 文件更简单，而写脚本则更复杂，但功能也更强。经过我的测试，包括修改分流规则在内的改动，是可以通过写 merge 文件达到的；但是如果我要添加某个新的代理节点到原本的代理组，那么似乎只能通过写脚本实现。
不过现在大家都有 AI，所以这件事毫无难度，直接让 AI写就可以了。
两种代理模式：System Proxy 与 TUN
当 Clash 读取了配置文件，它就能设置本地的 Clash 入口端口，并基于配置好的规则来对不同的进入端口的流量做分流。
但是，如何让流量进入端口呢？这是由操作系统决定的，Clash 一般会在客户端界面里提供 System Proxy 与 TUN 两种方式，我们称为“代理模式”，来修改操作系统设置，允许操作系统把流量送入本地的 Clash 入口端口（例如 127.0.0.1:7890）。
简单来说，TUN 模式比 System Proxy 更强大，后者能代理的流量前者都能代理。如果你不是程序员，不需要做软件开发/编程，那么你用 System Proxy 或 TUN 都可以。
下面的章节是给想要理解这两种代理模式的底层原理的人看的，没兴趣可以跳过。
System Proxy
System Proxy 是显式代理。Clash 先在本机监听 mixed-port，然后 GUI 把操作系统代理设置指向这个端口。
浏览器 / GUI App |
它的边界是：应用必须读取并遵守系统代理。Chrome、Safari、很多 Electron 应用通常会遵守；不少命令行程序不会自动遵守，例如 git、curl、brew、pip、npm、部分 CLI AI 工具。
所以，打开 System Proxy 不等于“本机所有流量都进入 Clash”。它只影响遵守系统代理的应用。
TUN
TUN 是路由接管。Clash 创建虚拟三层网卡，并通过系统路由表让更多 IP 流量进入 Clash。
应用 |
TUN 的覆盖范围更大。只要程序使用系统网络栈，它的流量就可能被路由进 Clash，即使它完全不知道 HTTP proxy 或 SOCKS proxy 是什么。
代价是路由复杂度更高。TUN 更容易和 VPN、局域网、Docker 网络、SSH 隧道、公司或学校内网产生交互。开启 TUN 后，应优先确认下面这些目标是否保持直连：
远程 SSH 服务器 IP |
实践上可以这样选：
只代理浏览器: |
代理软件与 VPN 的区别
你可能注意到，本文通篇在介绍的“代理软件”和你听说过的 VPN 很像。的确，二者在功能上很相似，都能用于翻墙。甚至代理软件的 TUN 模式和 VPN 一样都会创建虚拟网卡，也都可能修改路由表。
在 iPhone 上，各种代理软件的（无论是 System Proxy 还是 TUN 模式的）开启都会要求打开 iOS 的 VPN 按钮。
这其实是因为 iOS 的具体实现，这里就不沾展开了。
在中文互联网中，代理软件甚至经常被和 VPN 混用。然而，我们将看到他们是不同的。
具体来说，代理软件的 System Proxy 模式和 VPN 的差异很大，因为 System Proxy 并不会像 VPN 一样创建虚拟网卡，也不改变操作系统的路由表，它只是对操作系统的“系统代理”这个设置作了修改，不涉及网络层。
好吧，这么说有些模糊。其实现在的操作系统都会有个“系统代理”的设置，图形界面的 app，例如 QQ，微信，浏览器 等都会读取该设置。代理软件的 “系统代理” 模式，改的就是这个设置。
但是，“系统代理”设置不会改变系统的网络设置，它只对那些遵守该设置的应用（图形界面的app）有效。
因此， System Proxy 模式和 VPN 的差异是显然的。
最令人难以分辨和 VPN 的差别的是 TUN 模式，它同样会创建虚拟网卡，也会改变操作系统的路由表，可以说和 VPN 非常相似。但是，我接下来会证明 TUN 模式和 VPN 毕竟是不同的，
以典型的 VPN 协议 IPsec 为例：
应用 IP 包 |
VPN 的主要抽象是“把本机接入另一个网络”。原始 IP 包被封装进隧道协议，送到 VPN 网关（指 VPN 隧道的远端终点。比如我用XX大学的 VPN，那么 VPN 网关就是XX大学内部网络的边界路由器），再由 VPN 网关转发。它强调网络层连通性。
Clash TUN 的路径更像：
应用 IP 包 |
Clash TUN 使用了网络层入口，但后续不是通用 VPN 隧道。它会把流量交给规则代理系统，由 Clash 决定这条连接是直连、走某个代理节点，还是被拒绝。
一句话区分：
VPN: |
实战：观察 Clash TUN mode 的作用
本节给出一组 macOS 上的实验命令，用于观察本机网络接口、默认网关、路由表，以及开启 Clash / Mihomo TUN 前后的变化。
实验目标是验证：
不开 TUN: |
下面的输出经过脱敏和压缩。<LAN_IP>、<LAN_GATEWAY>、<PROXY_NODE_IP> 分别表示本机局域网地址、局域网默认网关、远程代理节点地址。
1. 不开启 TUN：默认从物理网卡出站
先关闭 TUN，查看本机网络接口：
ifconfig |
典型输出：
lo0: |
lo0 是环回接口。en0 通常是 Wi-Fi 或有线物理网卡。若 <LAN_IP> 是 192.0.2.202，netmask 是 0xffffff00，则示例中的本机处在 192.0.2.0/24 这个局域网中。192.0.2.0/24 是文档示例地址段，这里只用于说明子网推断方法。
接着查看默认路由：
route -n get default |
典型输出：
route to: default |
这表示当前系统的默认路由是：
目标前缀: default，即 IPv4 中的 0.0.0.0/0 |
默认路由是兜底路由。当目标地址没有命中更具体的路由项时，系统会使用它。
继续查看访问 8.8.8.8 的路由：
route -n get 8.8.8.8 |
不开 TUN 时，通常仍然命中默认路由：
route to: 8.8.8.8 |
这说明访问 8.8.8.8 的包会经由 <LAN_GATEWAY>，从 en0 发出。
现在抓取 en0 上到 8.8.8.8:443 的流量：
sudo tcpdump -i en0 -nn -c 10 'host 8.8.8.8 and tcp port 443' |
另一个终端发起连接：
nc -vz 8.8.8.8 443 |
典型抓包：
listening on en0, link-type EN10MB (Ethernet) |
这说明不开 TUN 时，访问 8.8.8.8:443 的原始 IP 包直接从物理网卡 en0 发出。如果所在网络无法直连 Google，这个连接可能持续重试而无法完成。
2. 开启 TUN：更具体的路由进入 utunX
打开 Clash / Mihomo TUN 后，再查看接口列表：
ifconfig -l |
典型输出：
lo0 en0 utun1 utun2 utun3 utun4 utun5 utun6 |
utunX 是 macOS 上的虚拟网络接口。系统中可能已经存在多个 utun，不一定全是 Clash 创建的；当前由 Mihomo 使用的是其中某一个，例如 utun6。
再次查看默认路由：
route -n get default |
典型输出：
route to: default |
注意，开启 TUN 后，默认路由仍然可能指向本地网关和物理网卡 en0。TUN 不一定通过改写 default route 接管流量。
再看访问 8.8.8.8 的路由：
route -n get 8.8.8.8 |
典型输出：
route to: 8.8.8.8 |
这说明 Mihomo 额外安装了更具体的路由，例如：
8.0.0.0/5 -> 198.18.0.1 via utun6 |
由于路由选择遵循最长前缀匹配，8.8.8.8 会优先命中 8.0.0.0/5，而不是 0.0.0.0/0 的默认路由。因此，该流量会先进入 utun6，再由 Mihomo 接管。
这里的 198.18.0.1 不是一个真实的物理网关。它是 Mihomo TUN / fake-ip 相关的虚拟地址，用于让系统把相关 IP 包交给 utun6，再由 Mihomo 在用户态读取和处理。
完整路由表也能验证这一点：
netstat -rn -f inet |
典型输出：
default <LAN_GATEWAY> UGScg en0 |
由于 8.8.8.8 ∈ 8.0.0.0/5，访问 8.8.8.8 时会命中：
8/5 -> 198.18.0.1 via utun6 |
这就是 TUN 接管生效的路由层证据。
3. 同时观察 TUN 接口和物理接口
接下来抓取 utun6 上到 8.8.8.8:443 的流量：
sudo tcpdump -i utun6 -nn -c 10 'host 8.8.8.8 and tcp port 443' |
另一个终端发起连接：
nc -vz 8.8.8.8 443 |
典型抓包：
listening on utun6, link-type NULL (BSD loopback) |
这说明访问 8.8.8.8:443 的连接已经进入 TUN 接口。utun6 上看到的是原始目标连接视图：应用想访问 8.8.8.8:443。
根据前面的机制，Mihomo 读取 TUN 中的 IP 包后，会恢复连接语义、执行规则匹配，然后重新建立一条出站连接。若规则结果是代理节点，那么物理网卡上不应再看到“本机直接连 8.8.8.8:443”这条连接。
验证这一点：
sudo tcpdump -i en0 -nn -c 10 'host 8.8.8.8 and tcp port 443' |
如果规则命中代理节点，通常没有输出：
listening on en0, link-type EN10MB (Ethernet) |
这说明从物理网卡发出的不是到 8.8.8.8:443 的原始连接，而是 Mihomo 新建的到代理节点的连接。原始目标信息会通过代理协议传给代理节点。
为了直接观察这条新连接，可以同时抓 utun6 和 en0。一次典型观察如下：
utun6: |
这两个事件只差几毫秒：utun6 上出现的是应用的原始目标连接，en0 上出现的是 Mihomo 新建的代理出站连接。若 <PROXY_NODE_IP> 是某个代理服务器地址，就说明这条连接已经被规则系统转发到代理节点，而不是从本机直接访问 8.8.8.8。
这个实验说明：TUN 不是把系统代理设置成某个端口。它通过路由表让流量进入虚拟网卡，再由 Mihomo 在用户态恢复连接语义、执行规则、创建新的出站连接。
实战：把 SSH SOCKS 节点加入 Clash
ssh -D 可以把远程服务器暴露成本机的 SOCKS5 入口。问题背景和单独使用方法见如何使用远程服务器作为本机的代理。
如果只把系统代理设为 127.0.0.1:1080，读取系统代理的应用都会走这台服务器。更合理的做法是：Clash 继续负责 System Proxy、TUN、规则和代理组；SSH SOCKS 只作为一个普通节点加入现有代理组。
应用 / 系统流量 |
这样可以复用订阅中已有的分流规则。例如：
OpenAI / YouTube -> PROXY |
只要把 SSH-SOCKS-NODE 加入 PROXY 组，并在 UI 中把 PROXY 当前出口选为 SSH-SOCKS-NODE，原本走 PROXY 的流量会经由远程服务器出站，原本 DIRECT 的流量仍然直连。
1. 启动 SSH SOCKS
先在本机启动 SOCKS5 入口：
ssh -N -D 127.0.0.1:1080 my-server |
my-server 换成真实 SSH 主机。必要时加上用户名和端口：
ssh -N -D 127.0.0.1:1080 -p 2010 [email protected] |
只要这个 SSH 连接保持不断，127.0.0.1:1080 就是一个可用的本机 SOCKS5 节点。
你也可以让 AI 帮你写一个脚本程序来在开机时自动执行
ssh -N -D 127.0.0.1:1080 my-server。
2. 修改 Clash 配置文件
前面提到，clash 的配置文件都是从订阅链接下载，并且会以频繁下载来更新的。因此我们不会直接改配置文件，而是使用代理软件提供的配置修改机制。这里我们用到了前面说的“全局扩展覆写配置”和“全局扩展脚本”两种修改配置的方式。
2.1. 用 Script.js 把节点插入已有代理组
首先，把该 SOCKS 代理节点 127.0.0.1:1080 添加到配置文件的代理节点中，并且加入某个现成的代理组。这样就可以直接用那个代理组的规则了。你也可以不这么做，单独给这个代理节点（或者创建代理组）设置分流规则，我只是为了简便。
把节点插入已有代理组的操作经过我的实验，似乎在 merge 文件中做不到，所以只能写全局脚本了：
function main(config) { |
需要改的通常只有两个值：
groupName: 要插入的现有代理组，例如PROXY、Proxy、节点选择。port:ssh -D在本机监听的端口，例如1080。
节点地址保持 127.0.0.1。Clash 只需要连接本机 SOCKS5 入口，真正的远程出口由 SSH 隧道负责。
注意，如果你之后改了
127.0.0.1:1080，比如改成了127.0.0.1:1088，那么你当然还要改这里的脚本。否则 clash 不可能知道你的本地 SOCKS节点在哪里。
做完这一步后，刷新 clash，你就能在对应代理组（这里是 “PROXY”）中看到这个新节点（这里是" SSH-SOCKS-NODE"）了。你可以通过 System Proxy 模式使用该节点，看是否生效。
2.3 防止 TUN 模式下出现自循环
接着我们得排除一个问题，如果我们让 clash 用这个节点，那么在 System Proxy 模式下是没问题的，但是 TUN 模式下会遇到一个问题。因为 TUN 模式会更改本地的网络设置（路由表），使得所有流量都走你选中的这个节点，这当然也包括了你连接该节点 127.0.0.1:1080 的流量（它是个 ssh 连接）。这就导致你对代理服务器的访问（通过 127.0.0.1:1080 ）需要先走代理服务器，造成死循环：
SSH 连接远程服务器 |
为了避免该问题，你只需要让让 SSH 服务器地址和本机回环地址直连（也就是不走代理）。这很简单，只需在 Clash Verge 的全局 Merge YAML 中加入：
prepend-rules: |
做完这一步后，TUN 模式也可以正常使用了。
2.4 重新加载配置
这一部很简单，你可以关闭再打开你的 clash；也可以在 clash 的 UI 上找 reload/重新加载 按钮并点击（找不到的话问 AI）。
使用顺序
日常使用顺序：
1. 启动 SSH SOCKS。 |
如果某个网站仍然不可用，先区分是 SOCKS 入口不通、远程服务器不能访问该网站，还是 Clash 规则没有命中：
curl --proxy socks5h://127.0.0.1:1080 https://example.com |