在防火牆開啟的狀態下，docker容器內部無法存取宿主機服務（能夠存取非宿主機的其他區域網路電腦的服務），解決方法：
1. 配置防火墙规则firewall-cmd --zone=public --add-port={port}/tcp --permanent，并重载防火墙规则firewall-cmd --reload
2. 启动容器时使用--net host模式
3. 关闭防火墙_補充：由於容器內請求的來源位址是使用的docker0網段的內網位址，宿主機防火牆無法辨識來源為非宿主機網段的docker0網段的內網位址請求，將其標記為未知來源，於是對請求進行了攔截，可透過添加防火牆來源規則（docker容器預設內網網段為172.17.0.0/16）：
<rule family="ipv4"> <source address="172.17.0.0/16" /> <accept /></rule>
進行解決或直接更改防火牆開放連接埠規則，即解決方法中的第1點進行解決，當然為了更方便，特別時服務個數特別多且連接埠變化比較快的時候，為了降低維護成本，在保證伺服器安全的情況下推薦使用第2或第3點解決方法
這也是微服務docker容器化部署時經常會遇到的坑，A服務訪問B服務，當A、B服務同時位於一台宿主機時無法訪問，當A、B服務位於不同宿主機時，訪問正常。案例如下：
同一宿主机微服务之间通信异常的血案：
微服务A能够正常请求AR
微服务B能够正常请求BR
但是微服务A某请求OR，内部访问BR，始终无法调用成功
原因：
centos的firewalld为开启状态时，微服务A内部发起请求时，请求无法从容器发出，即出现了调用不成功的情况（No route to host）
矛盾点：
spring cloud config 启动缓慢导致在测试的时候config服务启动后的一段时间内无法访问，让我们误以为关闭firewalld后无法接收请求，但又和其他服务又能正常访问出现了矛盾
验证：
docker创建四个nginx（8120、8787、8083、8084）容器，并创建ubuntu容器安装curl。
开启iptables，关闭firewalld，重启docker，启动五个容器，外部四个nginx访问成功，进入ubuntu容器使用curl访问，均成功
开启iptables，开启firewalld，重启docker，启动五个容器，外部四个nginx访问成功，进入ubuntu容器使用curl访问，均不成功
开启iptables，开启firewalld，重启docker，启动五个容器，外部四个nginx访问成功，宿主机配置firewall-cmd --zone=public --add-port=8120/tcp --permanent，进入ubuntu容器使用curl访问，8120访问，其他均不成功
宿主机配置端口使用iptables转发规则配置无效：
iptables -A INPUT -p tcp --dport 8120 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 8120 -j ACCEPT
iptables -A FORWARD -p tcp --dport 8120 -j ACCEPT
结论：
无论firewalld开启还是关闭，均不影响外部访问，宿主机需配置firewall-cmd --zone=public --add-port=8120/tcp --permanent（删除端口去掉--zone=public）同一宿主机才能相互访问成功
生产解决方案：
开启iptables，关闭firewalld
开启iptables，开启firewalld并配置开放端口
（开启或关闭firewalld后，需要重启docker）
iptables->ufw(ubuntu)iptables->firewalld(centos)相關推薦：docker教學
以上是如何解決docker內部存取不了宿主的詳細內容。更多資訊請關注PHP中文網其他相關文章！
