两条路径,先选一条

Linux 上的代理配置之所以让人觉得零散,是因为它同时存在两套差别很大的用法。一套是桌面场景:装个带界面的客户端,导入订阅,打开系统代理开关,体验和 Windows、macOS 差不多。另一套是服务器场景:没有图形界面,只有一个内核二进制加一份配置文件,由 systemd 拉起来常驻后台。

两者的配置文件格式往往相通,但操作方式完全不同。先确认你属于哪一类,再往下读对应章节,能省不少时间。如果你还没接触过命令行内核,建议先看sing-box 入门理解配置文件的基本结构,本文侧重的是 Linux 特有的那些坑。

准备工作

需要一条可用的订阅链接,以及知道自己的发行版和架构。执行 uname -m 查看架构,输出 x86_64 对应 amd64 包,aarch64 对应 arm64 包,下载错架构的二进制会直接报无法执行。

另外确认一下你的桌面环境。GNOME 与 KDE 的系统代理设置位置不同,后面会分别提到;如果你用的是 i3、sway 这类窗口管理器,则通常没有统一的系统代理概念,只能靠环境变量。

从哪里获取软件

Linux 上的安装渠道比其他平台更需要留意,因为很多教程会直接给出一行 curl ... | bash 的命令。这类一键脚本以 root 权限执行来源不明的代码,风险不言而喻,不建议使用——哪怕它看起来来自某个热门仓库。

推荐的顺序是:先查发行版官方软件源,部分工具已经进入 Debian、Fedora、Arch 的仓库或 AUR,用包管理器安装最省心;其次是项目的 GitHub Releases 页面,下载对应架构的压缩包或 deb/rpm 包,手动校验一下发布页提供的哈希值;图形客户端还可能提供 AppImage 或 Flatpak,同样以项目官方发布渠道为准。

不要从各类「软件下载站」「资源导航」获取二进制文件,代理客户端拥有你全部流量的可见性,来路不明的版本风险太高。

桌面环境:图形客户端路线

  1. 从上述官方渠道获取安装包。deb 系用 sudo dpkg -i 安装后执行 sudo apt -f install 补齐依赖;rpm 系用 sudo dnf install 指向本地文件;AppImage 则 chmod +x 后直接运行。
  2. 首次启动后进入配置或订阅页面,粘贴订阅链接并点击下载,等待节点列表出现。
  3. 把新导入的配置设为当前使用的配置。
  4. 在代理页面挑选一个延迟较低的节点,模式保持规则模式。
  5. 打开客户端主界面的「系统代理」开关。
  6. 到桌面环境的网络设置中确认代理项已被写入:GNOME 在「设置 → 网络 → 网络代理」,KDE 在「系统设置 → 网络 → 代理」。若显示仍为「无」,说明客户端没能自动写入,可手动改为手动模式并填入本地端口。

第 6 步是 Linux 特有的麻烦点。不同桌面环境写入系统代理的方式不一致,部分客户端只设置了 GNOME 的 dconf 键值,在 KDE 下就不会生效。手动填写时,HTTP 与 HTTPS 代理通常都指向 127.0.0.1 和客户端界面里显示的混合端口。

服务器环境:内核加 systemd 路线

没有桌面时,流程变成了标准的服务部署。

  1. 从项目 Releases 页下载对应架构的压缩包,解压后把可执行文件放到 /usr/local/bin/,并 chmod +x 赋予执行权限。
  2. 创建配置目录,例如 /etc/ 下以工具名命名的文件夹,把配置文件放进去。
  3. 生成配置。命令行内核一般不直接吃订阅链接,需要机场提供对应格式的配置文件,或用 curl 把订阅内容拉下来后借助转换工具生成。
  4. 先用前台方式运行一次做语法检查,多数内核提供类似 check 或 -t 的参数,确认配置无误后再做成服务。
  5. 编写 systemd 单元文件放到 /etc/systemd/system/ 下,指定执行路径、配置文件路径与重启策略。
  6. 执行 sudo systemctl daemon-reload,再 sudo systemctl enable --now 启动并设为开机自启。
  7. 用 systemctl status 查看运行状态,journalctl -u 服务名 -f 跟踪日志。

第 4 步不要跳过。直接做成服务再启动,配置有误时只会看到一个「启动失败」,还得回头翻日志,不如先在前台把错误信息看清楚。

让终端命令也走代理

这是 Linux 上被问得最多的问题:浏览器明明能访问了,git clone、curl、pip 却依然超时。原因是这些命令行工具不读取桌面环境的系统代理设置,它们只认环境变量。

使用场景做法生效范围
当前终端临时使用export http_proxy=http://127.0.0.1:端口 及同值的 https_proxy仅当前 shell 会话
单条命令临时使用curl -x http://127.0.0.1:端口 目标地址仅该条命令
长期生效把 export 语句写入 ~/.bashrc 或 ~/.zshrc该用户的所有新终端
sudo 执行时使用 sudo -E 保留环境变量该条 sudo 命令
包管理器在 apt/dnf 各自的配置文件中单独写代理该包管理器
Gitgit config --global http.proxy全部 git 操作

一个容易忽略的细节:很多程序还会读取 no_proxy 变量,建议同时设置它以排除本地地址,例如包含 localhost,127.0.0.1 以及内网网段,否则访问局域网服务时也会被绕到代理上,徒增延迟甚至失败。

若你希望所有程序不加设置就自动走代理,则需要 TUN 模式——由客户端创建虚拟网卡接管全部流量,原理见术语表的 TUN 模式条目。它在 Linux 上需要额外的网络权限,并会与部分容器网络产生冲突,不建议在跑着 Docker 的服务器上贸然开启。

验证连接是否生效

命令行环境下验证反而比图形界面更直接。最实用的一条是带 -x 参数的 curl:直接指定代理端口访问一个国外站点,若能返回内容,说明代理链路本身通;此时如果不带 -x 就失败,那问题不在代理,而在环境变量没设好。这一步能立刻把「代理不通」和「应用没走代理」两类问题分开。

图形环境下,再补两个常规测试:访问一个国内网站确认直连正常,访问一个平时受限的国外网站确认代理生效。

判断出口是否符合预期时,注意不要只看某个 IP 查询网站的结果,它本身可能被规则判定为直连。更可靠的做法是同时用带代理和不带代理的方式各请求一次,对比返回结果。

常见问题对照

现象常见原因处理方向
二进制无法执行架构不匹配或缺执行权限核对 uname -m,补 chmod +x
服务启动即退出配置文件语法错误前台运行看报错,或用内核自带检查参数
端口被占用已有实例在运行用 ss -tlnp 查占用进程后处理
浏览器可用终端不可用环境变量未设置参照上表设置 http_proxy
全部节点连不上订阅失效或本机网络问题换一个网络环境复测,核对订阅有效期
连上但网页打不开DNS 解析异常检查解析配置,见连上却无法上网
桌面代理开关无效客户端未写入当前桌面环境手动在桌面设置里填代理地址与端口
容器内程序不走代理容器有独立网络命名空间在容器内单独配置,或按需调整网络模式

日志是 Linux 上最大的优势,遇事先看 journalctl 或客户端自身的日志文件,大部分问题在日志里会直接给出原因,不必靠猜。

停用与还原

图形客户端:先关闭主界面的系统代理开关,再退出程序;随后到桌面环境的网络设置确认代理项已回到「无」。如果直接杀进程,代理设置可能残留,表现为退出后浏览器打不开网页,重新打开客户端再正常关闭一次即可。

服务器:sudo systemctl stop 服务名 停止运行,sudo systemctl disable 服务名 取消开机自启。别忘了收尾两件事——把 ~/.bashrc 里写死的 export 语句注释掉,并在当前终端 unset http_proxy https_proxy,否则服务已停而变量还在,所有命令都会指向一个没人监听的端口,报错信息还相当具有迷惑性。

如果开过 TUN 模式,还要确认虚拟网卡已被移除,可用 ip addr 查看是否有残留接口。

安全注意事项

代理进程能看到你机器上经过它的全部请求,因此谁提供的二进制、谁提供的配置文件,就等于谁获得了这份可见性。坚持官方源与官方 Releases,别执行不明来源的一键脚本,这条在 Linux 上比在其他平台更重要,因为这里的安装动作往往带着 root 权限。

配置文件里包含服务器地址与凭证,权限应设为仅 root 或所属用户可读;把它提交进 git 仓库是常见的失误,记得加进 .gitignore。订阅链接同样是账号凭证,不要写进公开的脚本或 Dockerfile。

服务器场景还要额外注意监听地址:本地代理端口默认只监听 127.0.0.1,如果为了给内网其他机器用而改成 0.0.0.0,请务必配合防火墙限制来源 IP,否则等于在公网开了一个任何人可用的开放代理,可能被他人滥用并给你带来麻烦。相关的合规与账号安全提示,建议对照风险说明一并了解。