Clash TUN 与 aTrust 并存方案：用 Docker 容器化解决 VPN 冲突

前言#

作为一个日常使用 Clash TUN 模式代理网络的开发者，我遇到了一个棘手的问题：实验室的 aTrust（深信服零信任 VPN）客户端和 Clash TUN 无法同时运行。两者的根本冲突在于——它们都想接管系统路由表。Clash 开了 TUN 模式后，aTrust 拨号成功但实际无法访问实验室内网资源；反之亦然。

经过一番折腾，我找到了一个优雅的解决方案：用 Docker 容器隔离 aTrust，再通过 SOCKS5 代理把隧道接回 Clash。本文记录完整的解决思路和配置过程。

问题分析#

冲突根源#

Clash TUN 模式：创建虚拟网卡，劫持所有系统流量，通过代理规则分流
aTrust 客户端：同样创建虚拟网卡，修改路由表，将实验室内网流量导入 VPN 隧道

两者同时运行时，系统路由表被反复改写，结果是——两个都工作不正常。

最初尝试：Clash 绕过规则#

我首先想到的是在 Clash 配置中添加绕过规则，让 aTrust 相关流量直接走系统网络，不经过 Clash TUN：

1
tun:
2
  enable: true
3
  stack: system
4
  dns-hijack:
5
    - any:53
6

7
# 尝试用 bypass 绕过 aTrust 进程和网段
8
bypass:
9
  - 10.0.0.0/8
10
  - 172.16.0.0/12

但这个方案失败了。aTrust 不仅仅是一个简单的 VPN 拨号工具，它的零信任架构涉及系统级网络接管、DNS 劫持、甚至内核级驱动。仅靠绕过 IP 段无法解决根本的路由冲突。

转换思路：隔离而非共存#

既然让两者在同一系统内”和平共处”行不通，那换个方向：把 aTrust 放进容器里，让它在自己的网络命名空间里独占路由。容器内的 aTrust 随意折腾路由表，完全不影响宿主机的 Clash TUN。然后通过 SOCKS5 代理端口把容器内的 VPN 隧道暴露出来，让 Clash 把实验室内网流量转发过去。

最终方案：Docker 容器化 aTrust#

核心思路#

1
┌─────────────────────────────────────────────────┐
2
│  宿主机 (macOS)                                   │
3
│                                                   │
4
│  ┌─────────┐    ┌──────────────────────────┐     │
5
│  │  应用流量 │───▶│  Clash TUN (代理网关)      │     │
6
│  └─────────┘    │                            │     │
7
│                 │  内网规则 ──▶ SOCKS5 :1080 ──┼─────┼──▶ Docker 容器
8
│                 │  其他规则 ──▶ 代理节点        │     │    aTrust VPN
9
│                 └──────────────────────────┘     │      (隔离网络栈)
10
│                                                   │
11
└─────────────────────────────────────────────────┘

Docker 配置#

使用 hagb/docker-atrust 镜像，这是一个专为容器化运行深信服 VPN 设计的项目：

1
version: '3'
2
services:
3
  atrust:
4
    image: hagb/docker-atrust:latest
5
    container_name: atrust-vpn
6
    cap_add:
7
      - NET_ADMIN          # 赋予网络管理权限，替代 privileged，更安全
8
    devices:
9
      - /dev/net/tun       # 挂载 TUN 设备，供 VPN 拨号使用
10
    environment:
11
      - PASSWORD=123456    # VNC 连接密码，可自行修改
12
      - USE_NOVNC=1        # 开启网页版 VNC，方便浏览器操作
13
    ports:
14
      - "1080:1080"        # SOCKS5 代理端口（给 Clash 用的）
15
      - "8888:8888"        # HTTP 代理端口（备用）
16
      - "8080:8080"        # 网页版 VNC 端口
17
    volumes:
18
      - ./atrust-data:/root  # 持久化登录状态，避免重启后掉线
19
    restart: unless-stopped

几个关键配置说明：

cap_add: NET_ADMIN：容器需要创建虚拟网卡，这是必须的网络权限。比直接给 privileged 更安全，只授予必要的权限
devices: /dev/net/tun：aTrust 拨号需要 TUN 设备，必须从宿主机挂载
USE_NOVNC=1：开启 WebVNC，可以通过浏览器访问容器内的 aTrust GUI 界面进行登录
volumes: ./atrust-data:/root：将登录凭证持久化到本地目录，容器重启后无需重新登录

Mac M 系列芯片注意：如果你使用的是 Apple Silicon (M1/M2/M3/M4)，需要在服务配置中添加 platform: linux/amd64，因为该镜像目前只有 x86 版本。Docker Desktop 会通过 Rosetta 2 自动转译运行。

启动与登录#

1
# 启动容器
2
docker compose up -d
3

4
# 浏览器打开 WebVNC 界面
5
# http://localhost:8080
6
# 输入密码 123456 连接

在 VNC 界面中登录 aTrust，完成认证。登录成功后，容器内的 aTrust 就建立了 VPN 隧道，此时 1080 端口的 SOCKS5 代理已经可用。

验证代理是否工作：

1
# 通过 SOCKS5 代理访问实验室内网地址
2
curl --socks5 127.0.0.1:1080 http://内网地址

Clash 配置：接入 aTrust 代理#

现在要把容器内的 VPN 隧道接入 Clash，让特定流量走 aTrust 实验室内网。

1. 添加代理节点：

1
proxies:
2
  - name: "🏫 aTrust实验室内网"
3
    type: socks5
4
    server: 127.0.0.1
5
    port: 1080

2. 添加代理组：

1
proxy-groups:
2
  - name: "Lab"
3
    type: select
4
    proxies:
5
      - "🏫 aTrust实验室内网"
6
      - DIRECT

3. 添加路由规则：

1
rules:
2
  # 实验室域名走 aTrust
3
  - DOMAIN-SUFFIX,lab.example.com,Lab
4
  - DOMAIN-KEYWORD,lab-oa,Lab
5
  # 内网 IP 段走 aTrust（加 no-resolve 避免DNS查询干扰）
6
  - IP-CIDR,10.0.0.0/8,Lab,no-resolve
7
  - IP-CIDR,172.16.0.0/12,Lab,no-resolve

将 lab.example.com 和 lab-oa 替换为实验室的实际域名和系统关键词。

DNS 配置：防止域名解析冲突#

Clash 开启了 fake-ip 模式后，会把 DNS 查询返回一个假 IP，然后通过规则匹配决定流量走向。但对于实验室内网域名，我们需要获取真实 IP 才能正确路由。在 Clash 配置中添加：

1
dns:
2
  enable: true
3
  enhanced-mode: fake-ip
4
  fake-ip-filter:
5
    - '*.lab.example.com'    # 实验室域名返回真实 IP，不走 fake-ip

这样 Clash 在处理实验室域名时会返回真实 IP 地址，确保流量能正确路由到 aTrust 代理。

最终效果#

配置完成后，日常使用中：

Clash TUN 正常工作：所有流量通过 Clash 代理，科学上网、广告过滤等功能不受影响
实验室内网自动穿透：访问实验室域名或内网 IP 时，Clash 自动将流量通过 SOCKS5 转发到 Docker 容器内的 aTrust 隧道
互不干扰：aTrust 在容器内有独立的网络栈，不会和宿主机的 Clash TUN 争抢路由表
一次登录，持久在线：通过 volume 持久化，容器重启无需重新认证

踩坑记录#

问题	解决方案
Mac M 芯片启动失败	添加 `platform: linux/amd64`，依赖 Rosetta 2 转译
容器重启后需要重新登录	挂载 `./atrust-data:/root` 持久化登录状态
实验室域名无法解析	在 `fake-ip-filter` 中排除实验室域名
SOCKS5 代理连接超时	检查 aTrust 是否在 VNC 中登录成功，确认隧道已建立
内网 IP 段规则不生效	添加 `no-resolve` 参数，避免 DNS 解析干扰 CIDR 匹配

总结#

这个方案的核心思想是用容器隔离替代路由共存。与其费力气让两个都要控制路由表的程序在同一系统里妥协，不如给其中一个独立的网络环境。Docker 提供了天然的隔离边界，SOCKS5 代理提供了标准化的隧道接入方式，两者结合优雅地解决了这个看似无解的冲突。

如果你也遇到了类似的 VPN/代理软件冲突问题，不妨试试这个思路。

本文基于实际操作记录整理，环境为 macOS + Docker Desktop + Clash Premium。