远程服务器工作流：把 Clash Verge Rev 跑在 VPS 上的那些坑与心得

🌐 为什么要把代理客户端搬到远程服务器上

远程办公已经成了我的常态，每天的工作基本都在 SSH 里度过。刚开始那两年，我在本地电脑上跑 Clash Verge Rev，代理开在本地，写代码、查资料、连远程开发机都还算顺畅。但慢慢地，我发现自己越来越依赖一种“服务器端代理”的模式：先在 VPS 上跑一个代理内核，然后本地通过 SSH 隧道或者直接让服务器帮忙转请求。

这么做的理由说起来也简单。第一，很多开发任务本身就在远程服务器上跑，比如拉取 GitHub 仓库、安装 pip 依赖、调用 OpenAI API，这些请求从服务器发起比从本地发起更直接，不用在本地和远程之间绕一圈。第二，本地电脑的代理客户端经常需要重新配置，尤其是我换了几次系统之后，每次装环境都折腾半天。把代理放在服务器上，本地只要一个 SSH 连接就能复用。第三，服务器 24 小时在线，不用担心本地电脑关机或者休眠导致代理中断。

当然，这套方案也有代价。配置复杂度比在桌面端点击几下高得多，出问题的时候排查也更麻烦。但当你习惯之后，那种“无论在哪台设备上，只要 SSH 连上服务器就能用”的体验，确实让人回不去了。如果你还没接触过 Linux 上的代理部署，可以先看看我之前写的 Linux 安装指南 和 Ubuntu 部署教程，那些内容算是这篇文章的前置知识。

🖥️ VPS 选型与系统准备

既然要在服务器上跑代理，选一台合适的 VPS 就是第一步。我自己用过三家不同的小厂和大厂，总结下来主要看三个指标：CPU 单核性能、内存大小、以及网络线路质量。代理内核本身不重，但如果你还要在服务器上跑其他服务（比如自建订阅转换、Web 面板、同步工具），内存最好有 1GB 以上。CPU 方面，Mihomo 内核在加解密时对单核性能敏感，所以单核主频高一点比核心数多更重要。

系统我一般选 Debian 12 或 Ubuntu 22.04 LTS，这两个版本的软件包足够新，同时社区文档也最丰富。安装系统时有一个细节：一定要确认 VPS 控制面板里已经开启 TUN/TAP 支持。有些便宜的 NAT 小鸡默认关闭了 TUN 模块，你后面怎么折腾都创建不了虚拟网卡。这个坑我踩过，当时折腾了整整一个下午，最后在控制面板里找到开关才解决。你可以用下面的命令检查 TUN 是否可用：

另外，建议在购买 VPS 之前先了解一下线路。对于国内用户，CN2 GIA 或者 CMIN2 这类优化线路在晚高峰时段的稳定性明显好于普通国际线路。如果你主要是用来跑自动化任务和 API 请求，对延迟不那么敏感，那普通线路也能凑合。但如果你打算把它作为整个家庭网络的出口，线路质量就得认真考虑了。这方面的取舍我在 为什么越来越多人不用 VPN 里也提到过一些。

⚙️ 无头内核部署：不装 GUI 也能跑

远程服务器通常没有图形界面，所以你不会在服务器上运行 Clash Verge Rev 的 Tauri 客户端。真正跑在服务器上的，是 Mihomo 内核 本身——也就是那个提供代理能力的二进制文件。Clash Verge Rev 在桌面端做了很多配置管理的工作，但在服务器上，你需要手动完成这些步骤。

部署流程其实不复杂。从 GitHub Releases 下载对应架构的 Mihomo 二进制文件，放到 /usr/local/bin/ 下，赋予执行权限，然后写一个配置文件放在 /etc/mihomo/config.yaml。配置文件的格式和 Clash Verge Rev 用的完全一致，你可以直接把桌面端的配置复制过来。唯一的区别是，服务器上的内核不提供图形界面，所以你需要通过 API 或者日志来观察运行状态。

这里有个容易忽略的点：桌面端配置里可能引用了本地文件路径，比如 Rule Provider 的 path 字段。在服务器上，这些路径需要改成服务器上的实际路径，否则内核启动时会报错。我一般会在服务器上重新整理一份专门的配置，只保留节点、策略组和规则，不包含任何和桌面环境绑定的设置。关于配置文件的完整结构，可以回顾 配置教程 里的字段说明。

🔌 TUN 模式的权限与内核模块处理

在服务器上开 TUN 模式，和桌面端最大的区别在于权限。桌面端你有管理员权限，点一下开关就行；服务器上通常只有一个普通用户，而创建虚拟网卡需要 CAP_NET_ADMIN 能力。最直接的方式是用 sudo 运行内核，但这样整个代理进程都是 root 权限，安全性不理想。

我一般采用两种折中方案。第一种是用 setcap 给内核二进制文件单独赋予网络管理权限：

这样普通用户执行时也能创建 TUN 网卡。第二种方式是创建一个专用的低权限用户，然后通过 systemd 的 AmbientCapabilities 给这个用户临时赋予能力。这种做法更干净，适合长期运行的服务。我个人推荐第二种，因为后期维护起来更规范。

另外，不同 VPS 的 Linux 内核版本差异很大，gVisor 堆栈在旧内核上可能会报错。如果你在启动 TUN 模式时看到“operation not permitted”或者“gVisor error”之类的提示，可以尝试把 stack 参数换成 system 或者 wfp（如果是 Windows 转 Linux 的场景就不适用 WFP）。这些坑和 TUN 模式断网排查 里提到的症状很像，本质上都是权限或者内核支持的问题。

🕵️ 远程环境下的 DNS 陷阱

在桌面端配置 DNS 已经够让人头疼了，在服务器上只会更复杂。服务器通常默认使用 /etc/resolv.conf 指定系统级 DNS，而 Mihomo 内核有自己的 DNS 模块。如果这两者没有协调好，就会出现“系统能解析但代理内部解析失败”或者反过来的情况。

我踩过的最大的一个坑是：服务器上装了 systemd-resolved，它占用了 127.0.0.53:53 端口，而 Mihomo 的 DNS 监听也试图绑定 53 端口，结果冲突导致 DNS 全面失效。解决办法是禁用 systemd-resolved，把 /etc/resolv.conf 指向一个公共 DNS 或者指向 Mihomo 自己的 DNS 监听地址。具体操作如下：

然后在 Mihomo 的配置里，把 DNS 监听地址改为 0.0.0.0:53，并开启 Fake-IP 模式。这样所有 DNS 请求都会经过代理内核，既防止了泄漏，又提高了在国内访问国外域名的解析速度。关于 Fake-IP 的详细原理，这篇深度解析 讲得很清楚。

🤖 自动化脚本：更新、监控、自愈

服务器上的代理跑起来之后，最怕的就是它悄悄挂掉而你不知道。所以我写了一套简单的脚本，定时检查内核状态，并在必要时重启服务。核心逻辑就是一个 cron 任务，每隔几分钟跑一次，检查 Mihomo 的 API 是否可访问。

然后在 crontab 里添加 */5 * * * * /opt/check_mihomo.sh，这样每五分钟就会自检一次。如果内核卡死或崩溃，脚本会自动拉起它。这个思路其实和 订阅更新时间 里提到的手动更新脚本很类似，只不过监控的对象从订阅变成了进程本身。

另一个常用脚本是订阅自动更新。桌面端的 Clash Verge Rev 有图形界面可以设置自动更新，但服务器上的 Mihomo 内核没有这个功能，你需要自己写脚本定时拉取订阅链接并重载配置。我一般用 curl 拉取订阅内容，保存到配置文件，然后调用 Mihomo 的 API 执行 PUT /configs 重载。整个过程可以完全自动化。

💻 日常使用：我的一天是怎么操作的

说说我每天实际的用法。早上到工位，第一件事是 SSH 连上服务器，用 systemctl status mihomo 看一眼代理是否正常运行。如果是正常状态，我就直接开始工作，终端里的 git pull、pip install、curl 默认就走服务器上的代理出口，不需要任何额外配置。

如果在本地电脑上想用浏览器访问国外网站，我会开一个 SSH 隧道，把服务器上的代理端口映射到本地。命令大概是 ssh -L 7890:127.0.0.1:7890 user@server，然后在本地浏览器里把代理设置为 127.0.0.1:7890。这样一来，浏览器的流量实际上是通过服务器出去的，而我本地不需要装任何代理软件。这种方式的好处是：只要 SSH 连得上，代理就可用，而且不用在每台设备上重复配置。

更省事的方式是在本地电脑上装 Clash Verge Rev，然后把节点设置成“通过 SSH 隧道连接服务器”。不过这个配置稍微复杂一点，需要你自己写一个 SOCKS 代理指向服务器的 SSH 端口。我大部分时候还是直接用 SSH 隧道，简单粗暴但有效。

🌙 那些让我凌晨三点抓狂的瞬间

这套工作流稳定运行了几个月，但中间也出过几次让我半夜爬起来处理的状况。印象最深的一次是：某天晚上我正用服务器跑一个长任务，突然发现所有网络请求都超时了。SSH 能连上，但服务器上 curl google.com 一直挂住。排查了半天才发现，是 Mihomo 的 DNS 模块把 /etc/resolv.conf 改掉了，而配置文件里的 DNS 服务器地址写的是 127.0.0.1，但 Mihomo 自己的 DNS 又崩了，形成死循环。

那次之后，我养成了一个习惯：永远保留一个备用的公共 DNS 在配置文件里，比如 223.5.5.5 或者 1.1.1.1，确保即使 Fake-IP 模块出问题，基础解析也不会完全挂掉。另外，我也会把每次修改的配置文件用 Git 管理起来，出问题就回滚到上一个版本。这个做法和 多设备同步方案 里讲的 Git 工作流是一致的。

还有一次是 VPS 厂商突然调整了路由，导致我的 IP 被临时拉黑，代理无法建立连接。这种问题通常需要提交工单或者换 IP，属于不可控因素。经历过一次之后，我开始在配置里加入多个不同厂商的节点作为备份，并通过策略组自动切换。这种冗余设计虽然平时用不到，但关键时刻能救命。

✍️ 写在最后

远程服务器代理这套方案，适合那些有一定 Linux 基础、并且经常在服务器上工作的人。它的优势不是“开箱即用”，而是“一次配置，到处复用”。你花一个周末搭好，之后几个月甚至几年都可以稳定使用，只需要偶尔更新一下订阅和规则。

如果你刚开始接触，建议先按照 Linux 安装指南 在本地的虚拟机里跑一遍，熟悉命令和配置结构之后，再迁移到 VPS 上。遇到问题的时候，除了看日志，也可以翻翻 常见问题 页面，或者去 GitHub Wiki 搜索关键词。这个过程可能有点慢，但每一步踩过的坑都会变成你自己的经验。