When using TUN mode, the ports of Docker containers are inaccessible from the external network

This issue is not limited to a specific configuration.
I have tested both Mihomo and Sing-box.

When using TUN mode on Linux, it affects running containers, making their mapped ports inaccessible.
Stopping TUN mode restores normal access.

预期：
docker pull 通过tun模式（当前如此）；
docker build 通过tun模式（当前如此）；
docker run的容器映射的端口可以被外部主机正常访问（当前不可用）；
容器内部最好可以通过主机的tun模式。

网络上其他同样问题：
Reference 1
Reference 2

外网访问内网 docker 问题

也可以说外网访问局域网内机器（非网关机器）的问题。我们这样配置好后，会发现无法从外网访问内网的 docker 服务（设置路由器端口转发）。可以通过手机流量访问测试。

我是参考该 github issue 受到了启发，最终解决了。

跳过 docker0 的 ip 范围。即跳过 docker 服务的出站数据包

sudo iptables -t mangle -A clash -p tcp -s 172.18.0.0/16 -j RETURN

然后以下是个人的推测，可能有误，仅供参考。

首先手机入站数据包经过路由器，NAT 到 docker 服务（网关机器）上。此时因为 dest ip 是内网 ip，clash 链 会跳过。DOCKER 链 接手处理，通过 DNAT 转发到了 docker0 bridge 网卡上，这几步都很正常。顺利到达 docker 容器。

随后是 docker 容器的出站数据包，此时数据包会从 docker0 bridge 发到宿主机的物理网卡 eth 网卡。这时数据包之于宿主机来说，是一个入站数据包。数据包会经过 PREROUTING 链，jump 到 clash 链，而此时的 dest ip 为手机的 ip 。会被转发到 clash 上处理，但这个数据包只在出站时转发给 clash 处理。入站的时候跳过了。估计 clash 无法处理这个数据包，可能就丢弃了。就出现了外网无法访问内网 docker 容器的问题。

所以根据 source ip 判断， 将 docker 容器的数据包也跳过。跳过后就解决了～

The report names no repository file, test, or entry point. Start by reproducing on Linux with TUN mode and a Docker container with a published port, then inspect the referenced iptables and Docker forwarding behavior; done means Docker pull and build still use TUN while published ports are reachable externally.