我用chaifeng的这个解决方案蛮久了，一直没啥问题。你要不去他issues区里搜搜，搜不到相关案例再问问他。 另外你nginx反代的docker地址，用127.0.0.1或172开头的最好，别填公网IP。之前看有些人反代本机内部容器，填公网IP，从外面绕一圈再回来，难绷
@Shrunk #34 我之前反代是用的npm，内部地址都是172.17.0.1+端口这样走的，然后在ufw里面也加上了（ufw route allow from 172.0.0.0/8 to 172.0.0.0/8），理论上容器间通信应该是没问题，目前推测是整个链路上有环节把某些大的包给拦截了（网上查到了PMTU 黑洞的说法，但是用AI排查了一遍发现没问题）
@SC6 #35 你把整个iptables里面的规则都拷给AI，可以让它再排查一下。不过我觉得你现在这个，是不是不太好？写的范围太大了。我一般用dockge面板，通过compose把有通信需求的几个容器写在同一个内部网络环境下。
@Shrunk #36 这个面板看起来还不错，之前都用的portainer，感觉可以互补一下。 然后iptables从规则上没分析出问题，就原生的＋ufwdocker修改了一部分。这个范围也是AI给的（，好像是大了点。。
@kejilion #21
bash <(curl -sL kejilion.sh)
这个脚本吗，看着功能好多，学习学习
@SC6 #31
这个是我之前发的 或许能帮到你
https://www.nodeseek.com/post-402175-1
@kejilion #30
大概看了下，感觉之前路线走复杂了，目前主要想实现的就是关闭除（80，443，ssh）以外的所有端口访问，然后用一个反代（比如nginx）连上所有docker来跑服务。
我用chaifeng的这个解决方案蛮久了，一直没啥问题。你要不去他issues区里搜搜，搜不到相关案例再问问他。
另外你nginx反代的docker地址，用127.0.0.1或172开头的最好，别填公网IP。之前看有些人反代本机内部容器，填公网IP，从外面绕一圈再回来，难绷
@Shrunk #34
我之前反代是用的npm，内部地址都是172.17.0.1+端口这样走的，然后在ufw里面也加上了（ufw route allow from 172.0.0.0/8 to 172.0.0.0/8），理论上容器间通信应该是没问题，目前推测是整个链路上有环节把某些大的包给拦截了（网上查到了PMTU 黑洞的说法，但是用AI排查了一遍发现没问题）
@SC6 #35
你把整个iptables里面的规则都拷给AI，可以让它再排查一下。不过我觉得你现在这个，是不是不太好？写的范围太大了。我一般用dockge面板，通过compose把有通信需求的几个容器写在同一个内部网络环境下。
@SC6 #33 那就继续摸索折腾吧 折腾使你快乐 哈哈
docker运行后 有没有执行奇怪的ufw指令
可能ufw的某些指令覆盖了docker某个防火墙规则？
@leic-山水 #22 ufw不会没有自启动吧
@Shrunk #36
这个面板看起来还不错，之前都用的portainer，感觉可以互补一下。
然后iptables从规则上没分析出问题，就原生的＋ufwdocker修改了一部分。这个范围也是AI给的（，好像是大了点。。