2026/9/23
开发工具分流规则配方
进程规则是使用 Specola Linux eBPF 后端的主要理由:不管工具认不认 HTTP_PROXY,都能按规则
分流。麻烦在于,规则看到的进程名不一定是你敲的那个命令。本文先说明如何查到真实名称,再给出
常用工具的写法。
所有示例都把流量发往名为 work 的代理组,请替换成你自己的代理或代理组。
查到内核看到的名字
PROCESS-NAME 匹配内核的 comm 字段:可执行文件的文件名,最多 15 个可见字节。在工具运行时
查看:
ps -o pid,comm,args -C git-remote-http
# 或者针对任意 PID
cat /proc/<pid>/comm
Specola 的连接日志也会显示每条连接的进程,通常这是确认规则该匹配什么的最快方法。
名字有歧义或太长时,改用 PROCESS-PATH。它匹配可执行文件的绝对路径,支持 * 和 ?:
"PROCESS-PATH,/home/you/.local/share/mise/installs/*,work"
内核可以预先检查精确进程名,但无法预先检查路径和通配符,因此这类规则会让更多连接绕经 Core。 能用精确名称时尽量用精确名称。
git
git clone https://… 并不自己建立连接,而是启动辅助程序 git-remote-https,它的 comm
被截断为 git-remote-http。SSH 协议的远端使用 ssh。
"PROCESS-NAME,git-remote-http,work",
"PROCESS-NAME,ssh,work",
ssh 规则也会影响你的交互式 SSH 会话。如果只想处理 Git 托管站点,改为按目标匹配:
"DOMAIN-SUFFIX,github.com,work",
"DOMAIN-SUFFIX,gitlab.com,work",
Go
模块下载由 go 可执行文件自己完成:
"PROCESS-NAME,go,work",
gopls 等语言服务器会自己发起请求,需要时单独添加。
Cargo
"PROCESS-NAME,cargo,work",
rustup 是另一个可执行文件,下载工具链还需要 "PROCESS-NAME,rustup,work"。
Docker
docker 命令只通过 Unix socket 和本地守护进程通信,拉取镜像的是守护进程:
"PROCESS-NAME,dockerd,work",
如果启用了 containerd 镜像存储,再加上 containerd,并通过日志确认实际连接镜像仓库的是哪个
进程。运行中容器内部的流量位于独立的网络命名空间,不在本文范围内。
Node.js:npm、pnpm、yarn
它们都是通过 #!/usr/bin/env node 启动的 JavaScript 程序,进程名是 node:
"PROCESS-NAME,node,work",
这条规则也会匹配其他所有 Node 程序,包括编辑器工具。想更精确时,按镜像仓库域名分流:
"DOMAIN,registry.npmjs.org,work",
Python:pip 与 uv
Python 工具的进程名取决于启动方式,虚拟环境还会带来各自的路径。uv 是单个原生可执行文件,
最简单:
"PROCESS-NAME,uv,work",
pip 请先用 ps 确认真实的 comm,或者直接按软件包索引的域名分流:
"DOMAIN,pypi.org,work",
"DOMAIN,files.pythonhosted.org,work",
规则顺序
规则自上而下,首条命中生效。一种规则变多后依然好读的排列方式:
[rule]
list = [
# 1. 明确拦截
"PROCESS-NAME,telemetryd,REJECT",
# 2. 精确进程名
"PROCESS-NAME,git-remote-http,work",
"PROCESS-NAME,cargo,work",
"PROCESS-NAME,go,work",
# 3. 域名
"DOMAIN-SUFFIX,corp.example,office",
"DOMAIN,registry.npmjs.org,work",
# 4. 网段
"IP-CIDR,10.0.0.0/8,DIRECT,no-resolve",
# 5. 路径和通配符
"PROCESS-PATH,/opt/internal/*,office",
# 6. 其余流量
"FINAL,DIRECT",
]
每次修改后先用 specola-core -t --config <配置文件> 校验,再重新加载。