彻底解决 macOS 上 aTrust 与 Clash Tun 模式冲突：Docker 隔离与全能分流指南

最近为了解决 Google Antigravity 网络问题，捣鼓了一下电脑的网络配置。

背景与起因

最近在 macOS 上开发时遇到一个很烦人的网络冲突问题。

我是使用自己的 mac mini 办公，公司的网络对外部网站的访问，限制得很严格，另外听说对访问流量也有监控，所以也是使用的自己的移动 WiFi（中兴的 F50）。

这就造成了一个麻烦点，访问公司内部资源时必须使用 aTrust 开启 VPN（aTrust 是臭名昭著的深信服开发的一个 VPN 工具，EasyConnect 也是他们公司的），而日常查资料和开发又离不开 Clash 来访问国际站点。

本来这两者共存也没什么大问题（我本来以为的，具体的下文再聊），但最近 Google 新推出的 AI 编辑器 Antigravity，必须在使用 Tun 模式下才能正常加载模型列表和问问题。

这就导致了一个死循环：

1. 打开 Clash 的 Tun 模式：接管系统网卡后，aTrust 的虚拟网卡被覆盖或路由失效，内网断连。
2. 关闭 Tun 模式：aTrust 正常了，但 Google Antigravity 无法正常使用。

后来在 LinuxDo 论坛 以及 V2EX 论坛 看到有人说可以使用 Proxifier 来管理 Antigravity 的网络，所以打算尝试 关闭 Clash Tun 模式 + 开启 aTrust + 开启 Proxifier 的模式，来解决上面的问题。

不过现实是，同时开启 Proxifier 和 aTrust 也是冲突的：Proxifier 总是检测到 aTrust Agent 发生循环链路（就算在 rules 中排除也会一直弹），且此时也无法访问公司内网。

归根结底，是两个软件都在抢夺宿主机的路由表和网络扩展控制权。

反正就是 aTrust 太恶心！

到这里，我其实有点绝望，不打算折腾了。直到我又搜索到一个好玩的项目：docker-easyconnect。

解决思路

既然宿主机的路由表太拥挤，解决办法就是把“脏活”隔离开。

我采用的方案是将 aTrust 扔进 Docker 容器里运行。容器内部通过 Tun 连接公司内网，然后暴露一个 SOCKS5 端口给宿主机。这样在 macOS 看来，aTrust 不再是一个修改系统网络配置的 VPN 软件，而只是一个普通的本地代理服务（Proxy）。接下来，在宿主机的 Clash 中添加这个 SOCKS5 代理，再把公司内网访问的 IP 分流到这个代理上就行了。

最后，由宿主机的 Clash 统一接管流量：

• 访问 公司内网 IP -> 转发给 Docker 容器的 SOCKS5 端口。
• 访问 google.com 或其他外网 -> 转发给机场节点。
• Clash 开启 Tun 模式 -> 解决 Antigravity 的流量劫持问题。

拓扑结构

在这个方案中，OrbStack 是个关键。相比 Docker Desktop，它的网络桥接更直观，容器可以直接通过 IP 或 mDNS 访问，省去了很多端口映射的麻烦。

整体流量走向如下：

graph TD
    subgraph macOS [macOS 宿主机]
        App[Android Studio / 浏览器 / 终端] -->|Tun 流量劫持| Clash
        
        Clash -->|Rule: 公司内网 IP| Proxy_Local[Proxy: Docker aTrust]
        Clash -->|Rule: Google/外网| Proxy_Remote[Proxy: 机场节点]
    end

    subgraph OrbStack [OrbStack 容器环境]
        Proxy_Local -.->|Socks5| Container[docker-easyconnect]
        
        subgraph Container_Internal [容器内部]
            Container -->|Tun 拨号| VPN_Interface
        end
    end

    VPN_Interface -->|内网流量| Company_Gateway[公司网关]
    Proxy_Remote -->|外网流量| Internet[互联网]

架构理清了，下面记录一下具体的配置过程。

实战步骤

1. 准备工作

• OrbStack: macOS 上 Docker Desktop 的最佳替代品，轻量且网络互通性极好。
• VNC Viewer: 用于访问容器内的图形界面（aTrust 登录框）。
• Clash: 我使用的是 FlClash，支持 Tun 模式即可。

2. 部署 aTrust 容器

这里使用 docker-easyconnect 这个项目。相比于直接 docker run，我更习惯用 docker-compose 管理，方便后续调整参数。

在任意目录下创建 docker-compose.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

services:
  atrust:
    image: hagb/docker-atrust:latest
    container_name: atrust
    # [新增] 特权模式：解决路由表报错和网络不稳定的关键
    privileged: true
    restart: unless-stopped
    
    devices:
      - /dev/net/tun
    # 虽然有了 privileged，保留 cap_add 也没坏处
    cap_add:
      - NET_ADMIN
    
    ports:
      # SOCKS5 端口：Clash 将通过这个端口连接内网
      - "1080:1080"
      # VNC 端口
      - "5901:5901"
      # HTTP 端口备用，这里可以注释掉或留着
      - "8888:8888"
    
    environment:
      - PASSWORD=123456
      - URLWIN=1
    
    volumes:
      - ./data:/root
      
    sysctls:
      - net.ipv4.conf.default.route_localnet=1

启动容器：

1

docker-compose up -d

3. 登录 VPN

容器启动后，aTrust 已经在后台运行，但还没登录。

• 下载 VNC Viewer，然后打开。
• 地址栏输入：127.0.0.1:5901。
• 输入密码（对应上面 yaml 里的 PASSWORD）。
• 此时你应该能看到熟悉的 aTrust 登录界面。输入服务器地址、用户名、密码。
• 登录成功后，不要关闭容器，直接关掉 VNC 窗口即可。

验证连接： 在终端里测试一下容器内部是否通了：

1

docker exec -it atrust ping <你公司内网的某个IP>

如果能 ping 通，说明容器内的 VPN 隧道已经建立。

4. 配置 Clash 分流

这是最关键的一步。我们需要告诉宿主机的 Clash：“凡是公司 IP 的请求，都转发给本地 1080 端口”。

我使用 FlClash 这款软件，可以直接在 配置 页面添加脚本：

新增脚本，然后直接填写如下代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

function main(config) {
  // ================= 配置区域 (请修改这里) =================

  // 1. 你的主力代理组名称
  // 打开 FlClash 看一眼，通常叫 "Proxy"、"节点选择"、"🚀 节点选择" 或 "Select"
  // 如果填错，那个境外 App 就没法联网。
  const MAIN_GROUP_NAME = "Proxies"; 

  // 2. 你的公司内网配置
  const COMPANY_PROXY_NAME = "🏢 公司内网";
  
  // =======================================================

  // === A. 定义公司内网信息 (请在此处修改) ===
  const COMPANY_PROXY = {
    name: "🏢 公司内网",
    type: "socks5",
    server: "127.0.0.1",
    port: 1080,
    password: "123456"
    // 如果有 username/password 也可以加在这里
  };
  
  // 必须走内网的规则 (优先级最高)
  // 优先处理：公司内网 IP
  const COMPANY_RULES = [    
    // --- 排除所有内网流量 ---
    // 10.x.x.x 网段
    "IP-CIDR,10.10.100.10/32,🏢 公司内网",
    "IP-CIDR,10.10.103.0/24,🏢 公司内网",
    // ... 其他 IP
    
    // 172.x.x.x 网段
    "IP-CIDR,172.30.0.0/23,🏢 公司内网",
    "IP-CIDR,172.30.12.0/24,🏢 公司内网",
    // ... 其他 IP
    
    // 192.168.x.x 网段
    "IP-CIDR,192.168.1.0/25,🏢 公司内网",
    "IP-CIDR,192.168.1.128/26,🏢 公司内网",
    // ... 其他 IP
  ];
  
  if (!config.proxies) config.proxies = [];

  // === 2. 将公司节点加入节点列表 ===
  config.proxies.unshift(COMPANY_PROXY); // 插到第一个，方便找

  // D. 把自定义规则合并到原有规则的最前面
  // 这样既保留了机场规则，又保证了你的规则优先级最高
  if (!config.rules) config.rules = [];
  config.rules = [...COMPANY_RULES, ...config.rules];

  return config;
}

此时，你不需要开启 Tun 模式，浏览器应该已经可以同时访问 google.com 和公司内网 IP 了。

解决 Antigravity 问题

回到最初的痛点：Antigravity 如果不走 Tun，根本拉不到模型列表，且无法正常对话。

现在宿主机的环境非常干净：

1. 没有 aTrust 抢占网卡。
2. 路由表未被污染。

方案 A：开启 Clash Tun 模式（推荐）

直接在 Clash 客户端打开 Tun 模式。

• Clash 创建虚拟网卡接管系统所有流量。
• Antigravity 发起的连接被 Clash 捕获。
• Clash 发现是 google.com 或相关 AI 域名 -> 走代理（成功）。
• Clash 发现是内网域名 -> 转发给 Docker-aTrust -> 容器内 Tun -> 公司内网（成功）。

至此，冲突完美解决。

方案 B：Proxifier 强制接管（备选）

如果你因为某些原因不想开 Tun 模式（比如想要更精细的进程级控制），可以使用 Proxifier。

1. Proxies 设置：添加 127.0.0.1:7890 (Clash HTTP 端口) 为主代理。

2. Rules 设置：

• Application: com.google.antigravity.helper;com.google.antigravity;Antigravity;language_server_macos_arm; (根据实际进程名添加，如果是 Intel 芯片的 Mac，则需要将最后一项改为 language_server_macos_x64)
• Action: Proxy HTTP 127.0.0.1:7890

这样能在不开启 Tun 的情况下，强行让 Antigravity 走代理。但这种方式需要多开一个 Proxifier App，所以个人更推荐方案 A。

总结

这套方案把“脏乱差”的 VPN 客户端关进了 Docker，还给了 macOS 一个清爽的网络环境。 虽然前期配置稍微麻烦点（写 Compose、配 Clash），但一旦跑通，后续的使用体验就是无感的。不再需要手动开关软件，也不用担心路由表爆炸，这才是开发环境该有的样子。

注意：我在本文前面提到，我本来以为 aTrust 和 Clash Tun 这两者共存也没什么大问题，但是后来别人提醒，aTrust 只要启动了，无论是否退出，都会有进程在后台监控流量。虽然“在后台监控流量”这件事，我没有去验证，但是我确实发现，当完全退出 aTrust 后，在 macOS 自带的活动监视器中，发现仍然有名为 aTrust Agent 的进程在后台活跃，这就让我产生了疑心。

所以，我最终决定，无论是否使用 Clash Tun 模式，aTrust 这个垃圾软件，注定必须要使用 Docker 容器隔离了。

致谢

• https://github.com/docker-easyconnect/docker-easyconnect
• https://linux.do/t/topic/1192827
• https://www.v2ex.com/t/1174715
• https://gemini.google.com