2026年Linux科学上网客户端完全指南：Clash Verge Rev、v2rayA、Hiddify 与 sing-box CLI 四条路线实战

Windows 和 macOS 用户装客户端，下载、双击、导入订阅，三分钟结束。同样的动作搬到 Linux 上，很多人卡的不是「不会用」而是「装不上、起不来、代理不生效」：deb 包装完是空窗、AppImage 双击没反应、TUN 模式永远提示权限不足、终端里 curl 通了浏览器还是国内 IP。这些问题不是客户端差，而是 Linux 把「代理」这件事拆成了四层——GUI 应用、Web 面板、内核进程、系统网络栈——选错层，后面每一步都在打补丁。

这篇把 Linux 上可用的四条路线一次性讲完：桌面 GUI 的 Clash Verge Rev、浏览器里管一切 v2rayA、吃满协议覆盖的 Hiddify（sing-box 内核）、以及无桌面服务器的正解 sing-box CLI + systemd。四条路线都给出可复制的安装命令、TUN 权限的正确开法、终端与开发工具（git / npm / pip / apt / docker daemon）的代理配置，以及 14 个 Linux 才有的坑。无论你用的是 Ubuntu 24.04、Fedora、Arch 还是无 GUI 的云主机，都能对上号。

开始之前先解决一件事：客户端只负责「怎么连」，出口质量取决于你导入的那条订阅。写完配置要测延迟时，建议拿一条自由猫这类 IEPL 专线线路做基准——专线在国内已有中转入口，Linux 上那套 DNS 与路由实验的变量会少很多，慢与不慢能一眼分清是客户端配错还是线路本身的问题。

一、先分清四条路线，再动手装工具

Linux 生态里「科学上网客户端」这个词其实混了四种完全不同的东西。先把它们分开，选型就变成填空题：

路线	代表工具	代理生效范围	适合谁	上手成本
桌面 GUI 客户端	Clash Verge Rev、Hiddify、FlClash	系统代理（GNOME/KDE 设置）+ TUN 可选	桌面用户，要托盘图标和点选操作	低
Web 面板	v2rayA	系统代理 / 全局透明代理（tproxy）	想一台机器管全屋、NAS、服务器	中
CLI 内核	sing-box、mihomo	靠配置文件与 systemd，无界面	无桌面服务器、需要精细路由	高
终端级代理	环境变量 + proxychains	仅当前 shell 的命令行程序	开发者临时拉包、跑脚本	最低

关键区别在「代理生效范围」这一列。很多人的困境是：装的是第二行的工具，却期待第四行以外的所有程序都自动走代理——GUI 客户端的系统代理只改桌面环境的环境变量和 gsettings，systemd 服务、Docker 守护进程、部分 Electron 应用压根不看这些；反过来，环境变量只影响 shell 里启动的程序，浏览器和图形应用照样直连。所以真正稳定的组合通常是「GUI/CLI 内核负责连接 + TUN 模式接管全部流量」，或者「内核常驻 + 需要透明代理时用 v2rayA」。

另一个必须先确认的前提是内核归属。Clash Verge Rev 和 v2rayA 不是同一种内核：前者是 mihomo（Clash Meta），后者是 Xray/V2Ray。这直接决定你的机场订阅能不能直接用——如果订阅里主推的节点是 Hysteria2 或 TUIC，Xray 系内核吃不下，只能换工具或者让机场提供 Clash 格式订阅。这一点在第三节会再展开。

二、路线一：Clash Verge Rev，桌面用户最省心的选择

Clash Verge Rev 是 Tauri 写的跨平台 GUI，Linux 版和 Windows/macOS 共用 mihomo 内核，功能没有缩水。它的优点是「订阅管理 + 策略组 + TUN」三件事都在一个界面里，缺点也明显：Linux 上的安装包格式和权限模型比另外两个平台复杂，第一次装最容易在这两处翻车。

2.1 按发行版选对包（选错包会浪费半小时）

# Debian / Ubuntu（下载 .deb 后本地安装，能自动补依赖）
sudo apt install ./Clash.Verge.Rev_2.x.y_amd64.deb

# Fedora / RHEL 系
sudo dnf install ./Clash.Verge.Rev_2.x.y_x86_64.rpm

# Arch / Manjaro：AUR
yay -S clash-verge-rev-bin

# 任意发行版兜底：AppImage
chmod +x Clash.Verge.Rev_2.x.y_amd64.AppImage
./Clash.Verge.Rev_2.x.y_amd64.AppImage

优先用 deb/rpm 而不是 AppImage，因为打包脚本会把 webkit2gtk、libayatana-appindicator 这类运行时依赖一起解决。Ubuntu 22.04 以上要的是 WebKitGTK 4.1：libwebkit2gtk-4.1-0；托盘图标依赖 libayatana-appindicator3-1，缺了它程序能开但没有托盘入口，最小化后就找不回来了。

AppImage 在部分较新发行版上会报 FUSE 相关错误，因为默认只有 FUSE 3 而老 AppImage 需要 libfuse2。两条路：装 libfuse2，或者不解压直接跑：

./Clash.Verge.Rev_2.x.y_amd64.AppImage --appimage-extract-and-run

2.2 订阅导入：把节点变成可用策略组

打开「订阅」页，粘贴订阅链接（机场后台复制的那一条）→ 导入 → 在「配置」页选中它。Clash 系订阅导入后会自动生成策略组，但刚导入的节点延迟全是未知，需要点一次测速。

这里有个容易被忽略的体验差异：同一家机场的订阅链接有时分「Clash 格式」和「通用格式」两个入口，前者直接是 YAML，后者需要客户端自己转。如果你手上有多个机场账号要合并成一个配置，别手动改 YAML，交给 Sub-Store 或订阅转换更稳。Linux 上导入订阅时如果反复提示「下载配置失败」，先确认客户端能不能访问订阅域名本身——这往往是订阅域名被墙而不是订阅失效，换一条稳定线路重新拉一次通常就好了，比如用万达云这类同时提供中转和 IEPL 专线的订阅，中转入口在国内、专线做备份，订阅拉取和节点连接用的不是同一条链路，单点故障的概率低一截。

2.3 三种「让系统走代理」的方式，优先级从低到高

系统代理：客户端改 GNOME/KDE 的代理设置 + 注入环境变量。只对尊重这些设置的程序生效，浏览器、Telegram 桌面版通常没问题，Docker 守护进程、systemd 服务、终端里已开着的 shell 无效。
服务模式：Clash Verge Rev 会装一个以 root 运行的 service 组件，内核以特权身份跑，TUN 不再每次要授权，退出客户端也不会留下半死的路由规则。桌面用户建议开这个。
TUN 模式：创建虚拟网卡接管全部 IP 流量，图形程序、命令行、容器（配置得当的话）都跟着走。这是唯一能覆盖「所有程序」的方式，代价是需要网络能力授权。

TUN 在 Linux 上失败的典型原因是缺少 CAP_NET_ADMIN。AppImage 便携方式下可以手动授予：

# 找到真实可执行文件路径后授予网络能力
getcap /usr/bin/clash-verge-rev
sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/bin/clash-verge-rev
getcap /usr/bin/clash-verge-rev   # 应输出 cap_net_admin,cap_net_bind_service=ep

注意 setcap 的作用对象是文件，一旦客户端升级、包管理器重写了二进制，能力标记就没了——这就是「昨天 TUN 还能用，今天又提示权限不足」的常见原因。要么每次升级后重跑一次，要么干脆用服务模式一劳永逸。

Clash Verge Rev 在 Linux 的配置目录是 ~/.local/share/io.github.clash-verge-rev.clash-verge-rev/，里面 profiles/ 放订阅配置、verge.yaml 放界面设置。备份时直接打包这个目录即可，跨发行版迁移也能用。

2.4 空白窗口与 Wayland 小坑

如果启动后窗口全黑或全白，多半是 WebKitGTK 在特定显卡驱动（尤其是 NVIDIA + Wayland）下的合成问题。用环境变量关掉硬件合成再启动：

WEBKIT_DISABLE_COMPOSITING_MODE=1 clash-verge-rev

另外 GNOME 上默认不显示托盘图标，需要装 AppIndicator 扩展，否则客户端最小化后会像「消失」了一样。这是 GNOME 的行为，不是客户端 bug。

三、路线二：v2rayA，浏览器里管一切

v2rayA 的形态很特别：本体是一个后台服务 + 一个网页控制台，你在浏览器里打开 http://127.0.0.1:2017 完成所有配置。这个设计让它在「一台机器装、多设备用」的场景里特别好使——装在 NAS 或旁路由上，你在手机浏览器里就能改规则，不用 SSH 上去敲命令。它也是四条路线里唯一把「全局透明代理」做到开箱可用的一个。

3.1 三种安装方式

# Debian / Ubuntu：官方 deb 包，装完自带 systemd 服务
sudo dpkg -i v2raya_2.x.y_amd64.deb
sudo systemctl enable --now v2raya

# Arch / Manjaro
yay -S v2raya

# Docker：透明代理需要 host 网络 + 内核模块可见
docker run -d --restart=always \
  --name v2raya --privileged --network=host \
  -v /lib/modules:/lib/modules:ro \
  -v /etc/v2raya:/etc/v2raya \
  -v /etc/resolv.conf:/etc/resolv.conf \
  mzz2017/v2raya

Docker 方式里三个挂载都不是可选项：/lib/modules 只读挂进去，v2rayA 才能在需要时加载 TPROXY 相关内核模块；/etc/v2raya 是配置持久化目录，不挂则容器重建后账号和订阅全丢；/etc/resolv.conf 关系到容器内的 DNS 解析。同时必须用 host 网络并给足权限，否则透明代理起不来——宿主机上想做全局代理，容器就不能待在默认的 bridge 网络里。

启动后打开面板，第一个动作是创建管理员账号，这一步会同时作为面板登录。面板除了 2017 端口，还会用到 20170–20172 一段端口做入站与分流，如果走 Docker 映射端口而不是 host 网络，这几个端口要一起带上。

3.2 代理模式：三种，别乱选

模式	生效范围	前提	什么时候用
不代理（仅出站）	只提供本地 SOCKS/HTTP 端口给指定程序	无	只给浏览器或个别程序配代理
系统代理	本机桌面环境的环境变量与设置	无特殊权限	桌面日常使用
透明代理（tproxy）	本机全部流量，可设「局域网设备也走」	root/特权、内核 TPROXY 或 nftables 支持	做全屋网关、旁路由出口

透明代理是 v2rayA 相对 GUI 客户端最大的优势：它不需要客户端常驻在用户会话里，装了就和系统服务一样跟着开机。iptables/nftables 规则由它自己写入，比手工抄 iptables 脚本可靠。代价是内核前提——极简容器或定制内核可能缺 xt_TPROXY 模块，此时只能退回系统代理模式。

另一处需要注意：v2rayA 跑的是 Xray/V2Ray 内核，协议覆盖是 SS / SSR / Trojan / Tuic / Juicity 这一系。如果你的订阅里主打 Hysteria2、TUIC v5 私有实现或 WireGuard 落地，v2rayA 吃不下，换下一节的工具。

四、路线三：Hiddify（sing-box 内核），协议覆盖最全的 GUI

如果你的机场订阅里同时有 VLESS、Trojan、Hysteria2、TUIC 甚至 Reality 和 WireGuard，sing-box 系客户端是最省事的选择，因为它按协议嗅探而不是按格式硬解析。图形界面上 Hiddify 是目前 Linux 完成度最高的一个：Flutter 写的 GUI + sing-box 内核，官方提供 deb 和 AppImage。

# AppImage 方式
chmod +x Hiddify-Linux-x64.AppImage
./Hiddify-Linux-x64.AppImage

# deb 方式（会自动建桌面入口）
sudo apt install ./hiddify-linux-amd64.deb

它的「简易模式 / 高级模式」切分很实用：简易模式下只要粘贴订阅链接、点连接，剩下的路由决策交给内置规则集；高级模式才暴露分片（fragment）、多路复用、自定义路由规则、WARP 出站这些参数。跨协议订阅混装时，Hiddify 支持订阅格式自适应，同一份机场订阅在别家客户端要手改格式，在这里往往直接能导入。

用 Hiddify 这类吃满协议的客户端，最大的收益是「能用上专线档位的精品节点」。专线机场的资源分配通常是往少而稳的方向走，节点数量比不上跑量型机场，但一条线路上挂的出口 IP 更干净：如果订阅里既有专线也有住宅 IP 出口，客户端侧不用做任何特殊配置就能按节点分组切换，SS-ID 就是这种纯 IEPL 思路——节点数少、协议以主流 VLESS/Trojan 为主，在 sing-box 系客户端里导入后基本不需要调参，适合拿来做「写进配置文件就不动」的稳定出口。

官方还提供 hiddify-core 这个纯命令行版本，本质是 sing-box 内核的封装。桌面用户用不上，但如果你要在无界面的服务器上保留图形客户端的配置习惯，它是个折中选项。

五、路线四：sing-box CLI + systemd，无桌面机器的正解

服务器、NAS、CI runner 上没有桌面环境，硬装 GUI 客户端只会带来一堆 GTK 依赖和一个随时会因为「没人登录」而退出的进程。这条路线的正确形态是：官方二进制 + 一份配置文件 + 一个 systemd 单元。

# 1. 装官方二进制
tar -xzf sing-box-1.x.y-linux-amd64.tar.gz
sudo install -m 755 sing-box-1.x.y-linux-amd64/sing-box /usr/local/bin/sing-box
sing-box version

# 2. 写配置后先做语法与配置校验（不会联网）
sing-box check -c /etc/sing-box/config.json

# 3. 前台试跑，确认无误再交给 systemd
sudo sing-box run -c /etc/sing-box/config.json

最小可用配置（TUN + 本地混合端口）大致长这样，重点是 route.auto_detect_interface——服务器有多张网卡（比如接了 WireGuard 或 Docker）时，不加它容易出现「代理自己连不出去」的回环：

{
  "log": { "level": "info", "timestamp": true },
  "dns": {
    "servers": [{ "tag": "local", "type": "dhcp", "detour": "direct" }],
    "final": "local"
  },
  "inbounds": [
    {
      "type": "tun", "tag": "tun-in", "interface_name": "singtun0",
      "address": ["172.19.0.1/30"], "mtu": 1500,
      "auto_route": true, "strict_route": true
    },
    { "type": "mixed", "tag": "mixed-in", "listen": "127.0.0.1", "listen_port": 7890 }
  ],
  "outbounds": [
    { "type": "direct", "tag": "direct" }
  ],
  "route": {
    "auto_detect_interface": true,
    "rules": [
      { "action": "sniff" },
      { "protocol": "dns", "action": "hijack-dns" },
      { "ip_is_private": true, "outbound": "direct" }
    ],
    "final": "direct"
  }
}

两个容易踩的点：auto_route 负责自动写路由表，strict_route 负责防止流量从 TUN 之外的网卡漏出去（也就是防泄漏），两者都开才接近客户端 TUN 模式的效果。以及新版本里「入站嗅探」已经从 inbound 的 sniff 字段迁移到 route 规则里的 {"action": "sniff"}，照抄老教程的配置会出现字段被忽略甚至启动报错——升级大版本前先看一次 changelog，比事后查错快。

至于订阅，服务器上不建议手工把节点抄成 JSON。用官方转换或订阅转换工具把机场订阅链接转成 sing-box 格式的 outbound 段落，再拼进配置，机场换节点时只需要重新拉一次。Sing-Box 完全配置指南里对 inbound/outbound/route 三段的结构和格式转换有完整拆解，第一次手写配置文件建议对着它抄一遍结构，比在服务器上反复试错省时间。

systemd 单元方面，官方 release 包里自带 sing-box.service，改一下 ExecStart 指向你的配置路径，systemctl enable --now sing-box 即可。TUN 需要特权，服务模式跑（系统级 unit）天然满足，这也是服务器比桌面省心的原因。

六、终端与开发工具怎么走代理（开发者刚需）

即使桌面代理跑通了，还有一个高频痛点：终端里的 git、npm、pip、apt、docker 该走哪里。这一节按「改什么文件」拆开讲。

6.1 环境变量：大小写都要设

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1,192.168.0.0/16,10.0.0.0/8

大小写不能只设一套：curl、wget 认小写，部分 Java 程序、Gradle、老版本工具只认大写。端口不要靠猜，GUI 客户端里显示的「混合端口」（mixed port）默认常见 7890，Socks 端口另算；用 ss -tlnp | grep 789 确认实际监听端口更稳。no_proxy 同样重要，漏了它会让本机服务、内网 API、Docker 守护进程的请求全部绕一圈代理，出现一堆莫名其妙的超时——这一点在同时用 Claude Code、Cursor 这类会调用本地端口的工具时尤其明显。

6.2 五个常用工具的具体改法

# git：全局写死，或只代理 GitHub
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global http.https://github.com/.proxy http://127.0.0.1:7890
git config --global --unset http.proxy        # 想撤销时

# npm / pnpm
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# pip
pip config set global.proxy http://127.0.0.1:7890

# apt（代理只对 apt 生效，不影响其他程序）
sudo sh -c 'printf "Acquire::http::Proxy \"http://127.0.0.1:7890\";\nAcquire::https::Proxy \"http://127.0.0.1:7890\";\n" > /etc/apt/apt.conf.d/95proxy'

Docker 是最容易搞错的一个：docker pull 走的是守护进程的代理，不是你的 shell 环境变量。在终端里 export 一堆变量再 docker pull，镜像该怎么超时还怎么超时。正解是给 docker.service 加 drop-in：

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo sh -c 'printf "[Service]\nEnvironment=\"HTTP_PROXY=http://127.0.0.1:7890\"\nEnvironment=\"HTTPS_PROXY=http://127.0.0.1:7890\"\nEnvironment=\"NO_PROXY=localhost,127.0.0.1\"\n" > /etc/systemd/system/docker.service.d/proxy.conf'
sudo systemctl daemon-reload && sudo systemctl restart docker
docker info | grep -i proxy     # 确认守护进程已读到代理

同样的道理适用于任何 systemd 服务：systemd 不继承你 shell 里的环境变量。用 systemctl show 服务名 -p Environment 看它实际拿到的变量，用 systemctl edit 服务名 加 [Service] 段落覆盖。这是「命令行能连、服务连不上」这类问题的根因。

6.3 proxychains：只转 TCP，别指望它救 UDP

sudo apt install proxychains4
# 编辑 /etc/proxychains4.conf，在 [ProxyList] 末尾加：
# socks5 127.0.0.1 7890
proxychains4 curl -I https://www.google.com

proxychains-ng 靠 LD_PRELOAD 劫持 socket 调用，好处是不用改程序配置，缺点是只处理 TCP。走 UDP 的应用（QUIC、游戏、部分语音工具）它管不了，静态编译的程序（多数 Go 二进制、部分 Rust 工具）也可能劫持失败。所以它适合临时救急，不适合当长期方案——需要全覆盖时回到内核的 TUN 模式。

顺带说一个容易被忽略的场景：在服务器上跑自动化脚本、爬虫、多账号工具时，出口 IP 的「干净程度」比速度更关键。同一台机器上切节点不改变出口 IP 类型，如果业务对 IP 画像敏感，选订阅时要专门挑住宅 IP / 原生 IP 出口的节点——这类节点在客户端侧不需要任何特殊配置，导入后单独分组即可。仙路湾的定位就是住宅 IP / 原生 IP 出口，配合 Linux 上这套「同一份配置、按节点分组切换」的做法，脚本和人工操作可以走不同出口，互不干扰。

七、DNS 是 Linux 上最大的变量

Ubuntu 从 18.04 起 /etc/resolv.conf 默认是指向 127.0.0.53 的 systemd-resolved 存根。这带来两个后果：一是应用层代理如果依赖系统 DNS 解析域名，解析请求走的是本地存根 → 上游 DNS，境外域名很容易被污染；二是你手工改了 /etc/resolv.conf 重启后被覆盖。

resolvectl status              # 看当前接口 DNS 与上游
resolvectl query google.com    # 看真实解析路径与返回 IP
ls -l /etc/resolv.conf         # 确认是否指向 stub

三条修法按侵入性排序：

客户端内置 DNS（推荐）：在 Clash/mihomo 或 sing-box 配置里启用 DNS 模块，让代理内核自己解析，不依赖系统存根。TUN 模式下 sing-box 还会在 Linux 上写入 iproute2 规则劫持 DNS 请求，等于把解析权收归内核。
改 resolved.conf：/etc/systemd/resolved.conf 里设置 DNS= 与 DNSOverTLS=，改完 systemctl restart systemd-resolved。这是「整机都换 DNS」，包括不走代理的流量。
分流而非全换：国内域名用国内 DNS、境外域名走代理解析，规则集（geosite / rule-set）能表达这种分流。只在 TUN 或内核 DNS 模式下才做得到，纯环境变量代理做不到。

如果发现「命令行 curl 通的、浏览器还是国内 IP」，八成是系统代理没生效而 TUN 没开；如果发现「部分域名解析到错误 IP」，八成是 DNS 泄漏，用客户端防泄漏完全指南里的 DNS 泄漏检测步骤定位，比盲改配置快。各种 DNS 方案（DoH/DoT、递归查询、污染对抗）的原理与配置细节，DNS 解析原理与优化指南讲得更系统，遇到解析类问题可以对症翻。

7.4 分流规则怎么写：国内直连、境外走代理

全局模式用久了都会碰到两类麻烦：访问内网服务绕一圈变慢，国内站点反而因为出口在境外而变得不稳定。正解是把判断权交给内核，让它按域名和 IP 决定流向。mihomo 系内核用 GEOSITE/GEOIP 加规则集表达这套逻辑，规则表是「从上往下，第一条命中即生效」：

rules:
  - RULE-SET,private,直连            # 内网地址永远直连
  - GEOSITE,category-ads-all,REJECT  # 广告域名直接拒绝
  - GEOSITE,cn,国内直连
  - GEOIP,CN,国内直连
  - MATCH,代理                       # 剩下的全部走代理

顺序不能随手调换：把 MATCH 提到前面就等于全局代理，后面所有精细规则都不会被执行——这是「我明明写了分流规则却完全没效果」最常见的原因。sing-box 用 route.rules 加 rule_set 表达同一套优先级，动作分为 route（改流向）、reject（拒绝）、sniff（协议嗅探）、hijack-dns（接管 DNS）几类，语法不同但思路一致：先特殊后一般，兜底规则永远放最后。

规则集从哪来要做取舍。机场订阅自带的规则集最省事，但更新节奏取决于机场；客户端内置或远程拉取的更新及时，代价是首次启动要联网下载（偏偏在还没连上网的时候最尴尬）；自建规则集最可控，但要自己承担维护成本。多数人的平衡点是「用内置规则集，只对自己在意的少量域名写自定义规则」。

7.5 改完配置怎么验证

DNS 和路由方面的改动最擅长「看起来生效了」。按下面顺序逐条验证，能避免在错误状态上继续调参：

resolvectl query example.cn         # 国内域名应解析到国内 IP
resolvectl query google.com         # 境外域名应返回可用 IP
curl -s https://api.ipify.org       # 出口 IP 应等于节点 IP
ss -tlnp | grep -E '789|2017'       # 内核是否在监听预期端口
ip route show table all | head -20  # TUN 是否写入了路由条目

五条全部符合预期，再谈速度与稳定性。任何一条不对，先修它——在错误的路由状态上测出来的延迟数字没有参考价值，还会把排查方向带偏。

八、16 个 Linux 专属坑与对应修法

#	现象	根因	修法
1	TUN 报权限不足	缺 CAP_NET_ADMIN	setcap 授权或用服务模式；升级后需重做
2	AppImage 双击无反应	缺 libfuse2	装 libfuse2 或加 --appimage-extract-and-run
3	窗口全黑/全白	WebKitGTK 合成问题	WEBKIT_DISABLE_COMPOSITING_MODE=1
4	最小化后找不到窗口	GNOME 无托盘	装 AppIndicator 扩展
5	改 /etc/resolv.conf 无效	systemd-resolved 存根接管	改 resolved.conf 或用内核内置 DNS
6	docker pull 不走代理	守护进程不读 shell 变量	给 docker.service 加 drop-in 并重启
7	服务连不上外网	systemd 不继承环境变量	systemctl edit 加 Environment=
8	IPv6 仍走直连	TUN 只接管 IPv4 或双栈未处理	配置 IPv6 地址或显式禁用
9	节点全红、延迟测不出	系统时间偏移	chrony/systemd-timesyncd 同步时间
10	订阅拉取失败	订阅域名本身被墙	先连通再拉订阅，或换稳定线路
11	7890 端口被占用	GUI 与 CLI 内核同时启动	同一时间只留一个内核
12	容器内无网络	默认 bridge 网络看不到 TUN	用 host 网络或显式配置容器代理
13	SELinux/Firewalld 拦截	发行版强制策略	放行内核与所需能力，勿整体关闭
14	流量走了代理但 DNS 泄漏	应用级代理不接管 DNS	开 TUN 或用内核 DNS + 分流规则
15	写了分流规则却全量走代理	兜底的 MATCH 规则被放在了前面	调整顺序，特殊规则在前、兜底在后
16	第一次启动就提示规则集下载失败	远程规则集需要联网，而代理此刻还没就绪	先直连拉一次规则集，或切本地规则集

这 16 条里 1、5、6、7 占了实际求助量的大头。排错的正确顺序是从「内核有没有起来」开始往下：确认端口在听、确认出口 IP 变了、确认 DNS 走的是代理解析、最后才怀疑系统级设置。这套分层定位方法和报错信息的对应关系，客户端故障排查完全指南里有完整的五层模型，卡住时按层走比随机改配置高效得多。

九、四条路线横向对比

维度	Clash Verge Rev	v2rayA	Hiddify	sing-box CLI
安装方式	deb / rpm / AppImage / AUR	deb / AUR / Docker	deb / AppImage	官方二进制 / 发行版仓库
交互界面	桌面 GUI + 托盘	浏览器 Web 面板	桌面 GUI	命令行 + 配置文件
内核	mihomo（Clash Meta）	Xray / V2Ray	sing-box	sing-box
系统级代理	系统代理 + TUN	系统代理 + 透明代理（tproxy）	系统代理 + TUN	TUN
协议覆盖	SS / VMess / VLESS / Trojan / Hysteria2 / TUIC	SS / SSR / Trojan / Tuic / Juicity	覆盖最全，含 Reality、WireGuard、SSH	最全，可精细到分流动作
订阅格式	Clash YAML 为主	通用链接 / 多种格式	自适应，多格式通吃	需转换或手写 outbound
远程管理	否	是（浏览器，可局域网访问）	否	是（SSH）
资源占用	中（Tauri + WebKit）	轻（纯后台服务）	中（Flutter）	最低
无桌面服务器	不推荐	可用	不推荐	最佳

表格里有一条容易被忽视：mihomo 与 sing-box 都支持 Hysteria2，而 Xray 系内核不支持。选客户端之前先看自己机场订阅里哪些协议是主推，比先选工具再找能用的节点省事得多。同理，如果你的订阅以 Clash YAML 下发，Clash Verge Rev 零配置成本；如果机场只给通用链接且节点协议很杂，Hiddify 或 sing-box 系更合适。Clash Verge Rev 从入门到精通里有订阅管理与策略组配置的完整步骤，桌面路线确定后可以直接照着配。

十、怎么选：按机器和使用场景

个人笔记本（Ubuntu / Fedora 桌面）：Clash Verge Rev + 服务模式 + TUN。图形操作省心，服务模式解决权限反复失效。
开发机 / 工作站：Clash Verge Rev 或 Hiddify 负责内核，再配终端环境变量与 git/npm/pip/docker 五项。重点是把 no_proxy 设全，别让本地服务绕代理。
NAS / 旁路由（要带全屋设备）：v2rayA 透明代理，浏览器里管理，开机自启，不用保持登录会话。注意内核为 Xray 系，协议不匹配时改用 sing-box CLI 做透明网关。
无桌面云服务器 / CI runner：sing-box CLI + systemd unit。别装 GUI，别指望靠环境变量覆盖所有进程。
老旧机器 / 内存紧张：sing-box CLI 或 v2rayA，避开 Electron/WebKit/Flutter 带来的 GUI 开销。
要多设备共用一份订阅：内核常驻 + 局域网共享混合端口，同时确认机场允许的设备数上限，必要时用多机场订阅合并（负载均衡 / 故障转移）分摊设备数。

多机场合并这件事在 Linux 上有额外收益：GUI 客户端能同时导入多份订阅并做负载均衡，但服务器场景更适合在内核配置里用策略组表达。相关的订阅合并、格式转换与节点重命名，订阅转换与 Sub-Store 完全指南有全套做法，比在每台机器上手工维护配置可复制。

还有一条容易被忽略的成本项：设备数。机场套餐普遍限定同时在线设备数，而 Linux 用户手里往往有笔记本、开发机、虚拟机、容器好几处出口，很容易超限触发风控。两种应对方式：用多机场订阅合并，把设备分散到不同订阅；或者把代理收敛到一台常驻机器上（v2rayA 或 sing-box CLI 做局域网出口），其他设备共享这一个出口——既省设备数，也少配几台机器。

10.1 上线前自检清单

选定路线后，按这七条过一遍再算配置完成：

内核进程只有一个，端口确实在监听（ss -tlnp 能找到对应条目）；
出口 IP 与所选节点的归属地一致；
DNS 没有泄漏，境内域名解析到境内 IP；
IPv6 要么被接管要么显式关闭，不留直连口子；
系统代理与 TUN 没有同时开启；
终端与常用开发工具（git / npm / pip / docker）各自验证过一次；
重启机器后代理能自动恢复（服务模式或 systemd 托管）。

七条里最容易漏掉的是最后一条：手动点开客户端能上网，重启后忘了开，第二天所有定时任务和自动化脚本全挂。把内核交给系统服务管理，等于把「记得开代理」这件事从人身上拿掉。

十一、FAQ

Q1：Linux 上有没有像 Windows 那样「装完就能用」的客户端？
有，但要看发行版。Ubuntu/Debian 装 .deb 最接近开箱即用；Arch 走 AUR；Fedora 用 rpm。跨发行版最省心的形式反而是 AppImage，代价是要自己补依赖（FUSE、WebKitGTK、AppIndicator）。

Q2：为什么我开了系统代理，终端里还是不通？
系统代理只改桌面环境设置和当前用户环境变量，已经打开的 shell 不会重新读；而且 systemd 服务完全不吃这套。终端里临时用需要手动 export，长期用建议给具体工具写死配置或直接上 TUN。

Q3：TUN 模式和系统代理能同时开吗？
不建议。两者叠加会让部分流量被处理两次，出现延迟异常或回环。选了 TUN 就关掉系统代理。

Q4：setcap 授权后 TUN 能用，过几天又不行了？
客户端或包管理器升级时重写了二进制文件，能力标记随之丢失。重跑 setcap，或改用服务模式（内核以独立服务身份运行，不受升级影响）。

Q5：v2rayA 和 Clash Verge Rev 能同时装吗？
能装，但不要在系统级代理或透明代理层面同时启用，两者都写路由和代理设置时会互相干扰。同一时间只让一个内核接管流量。

Q6：服务器上装 GUI 客户端行不行？
技术上能跑（配合 X11 转发或 VNC），但没有必要：依赖重、内存占用高、没人登录时会话退出就断。服务器用 sing-box CLI + systemd 更稳，也更容易写进部署脚本。

Q7：为什么订阅在别的平台能用，Linux 客户端说格式错误？
大概率是格式不匹配：Clash 系要 YAML，Xray 系要通用链接，sing-box 要自己的 JSON。用订阅转换生成对应格式，或换成格式自适应能力强的客户端。

Q8：怎么验证代理真的生效了？
三条命令按顺序：curl -s https://api.ipify.org 看出口 IP；resolvectl query google.com 看解析路径；ss -tlnp | grep 789 看内核有没有在监听。三条都符合预期，再谈速度。

Q9：TUN 开了但 IPv6 网站仍然直连？
TUN 只接管它配置了的地址族。要么在配置里补 IPv6 地址段，要么显式禁用 IPv6，否则会出现「IPv4 走代理、IPv6 直连」的泄漏。

Q10：多台 Linux 机器想共用一份配置，怎么做？
把内核配置文件（或客户端配置目录）纳入版本管理，机器之间同步同一份；账号密码类信息用环境变量或单独的 secrets 文件注入。GUI 客户端的配置目录路径是固定的，直接打包迁移即可。

Q11：远程规则集下载失败，代理还能用吗？
能启动但分流会不可靠——规则集缺失时多数内核会退回兜底规则，表现为「该直连的绕出去了」。修法是先直连拉一次规则集，或者换成本地规则集，别在缺规则集的状态下长期使用。

Q12：TUN 模式下 Docker 容器默认走代理吗？
不走。容器在自己的网络命名空间里，看不到宿主机的 TUN 网卡。要么让容器用 host 网络，要么在容器内单独配代理（构建镜像时用 --build-arg 传代理是常见做法）。这也是「宿主机代理正常、容器拉包超时」的原因。

Q13：笔记本合盖休眠再打开，代理就失效了？
多见于 TUN 模式：休眠会清掉虚拟网卡和路由条目，唤醒后内核没有重新拉起。检查客户端是否有「唤醒后自动重连」选项，或者干脆用 systemd 服务模式让内核由系统管理生命周期。

Q14：选 GUI 客户端还是 CLI 内核，有没有一句话的判断标准？
有：这台机器上有没有人需要「看着图标操作」。有就用 GUI，没有就用 CLI + systemd。两者内核能力差不多，差别在运维方式，不在速度。混合场景可以一台 GUI 客户端加几台 CLI 内核，共用同一份订阅结构。

十二、推荐阅读

Windows 科学上网客户端横评与配置指南——同样四款内核在 Windows 上的表现与配置差异，双系统用户对照着看能省一次踩坑。
macOS 科学上网客户端横评与配置指南——Apple 平台的 TUN 实现与授权模型和 Linux 完全不同，跨平台用户的另一半拼图。
多机场订阅管理与策略组高级配置——负载均衡、自动切换与故障转移的具体写法，Linux 上多订阅合并绕不开这一篇。