容器网络隔离：加速发生在容器侧，不发生在宿主机

network namespace

内核为每个网络栈维护的独立环境，容器各自持有一份。路由表、策略规则、防火墙规则与解析配置都按命名空间划分，容器内的改动不会传播到宿主机或其它容器。

main 表

每个命名空间内的默认路由表，本地地址在 local 表中优先匹配，未命中其它表时回落到 main 表。宿主机 main 表保存原有默认网关，快连VPN 不向其中写入任何内容。

策略路由表 100

容器命名空间内额外创建的路由表，用于承载加速出口。表编号为自定义约定，示例口径取 100；它的作用是给加速流量一个独立的出口决策区，从而避免改动 main 表的默认路由。

隧道设备

容器内创建的虚拟网卡，作为表 100 的出口。查表命中表 100 的连接经由该设备进入加速链路，设备本身的建立与销毁都发生在容器内部。

fwmark

附加在套接字上的标记位，规则通过它把「需要加速的连接」与容器内其它连接区分开。标记在容器内设置，宿主机其它命名空间的规则不参与匹配。

容器内的规则与表 100

进入容器查看策略路由规则：规则自上而下匹配，带标记的连接查表 100，其余连接仍按容器原本的 main 表转发。下面是命令与输出形态的示例。

# 查看容器命名空间内的策略路由规则
$ docker exec kl-proxy ip rule show
0:      from all lookup local
100:    from all fwmark 0x1 lookup 100   # 带标记的连接查表 100
32766:  from all lookup main            # 其余连接按容器原 main 表转发
32767:  from all lookup default

# 查看表 100：加速出口指向容器内的隧道设备
$ docker exec kl-proxy ip route show table 100
default dev kl-tun0                  # 隧道设备承接表 100 的出向流量

1. 记录接入前的宿主机路由状态

   先取基线。基线本身包含宿主机上其它组件留下的规则，后续对比以它为准。

   sudo ip rule show  | tee /tmp/rule-before.txt
   sudo ip route show table main | tee /tmp/main-before.txt

2. 在容器内发起真实业务请求

   必须由容器内的进程发起，宿主机侧发起的请求不经过容器命名空间，验证不到加速路径。

   docker exec kl-proxy curl -sS -o /dev/null https://registry.npmjs.org/

3. 再次记录宿主机路由状态

   请求完成后立即记录，确保加速链路的建立过程已经结束。

   sudo ip rule show  | tee /tmp/rule-after.txt
   sudo ip route show table main | tee /tmp/main-after.txt

4. 对比两次输出

   两次 diff 均无输出且退出码为 0，即表示宿主机路由在整个过程中未被改写。

   diff /tmp/rule-before.txt /tmp/rule-after.txt ; echo "rule exit=$?"
   diff /tmp/main-before.txt /tmp/main-after.txt ; echo "main exit=$?"

完整部署顺序、启动参数与验证步骤见 快连VPN 部署文档。若验证中发现加速链路不通但宿主机状态正常，优先检查分流规则的命中维度与出口配置；容器镜像的获取与来源核验见 来源核验与防钓鱼。