类型：虚拟化技术
简介：基于操作系统层级的虚拟化技术，将软件与其依赖项打包为容器。
Docker网络问题常见表现包括：容器之间无法访问，宿主机能访问但外网不能访问，域名解析失败，端口映射后页面打不开，反向代理返回502，应用提示数据库连接失败。看到这些现象时，不要马上重装容器，应先判断问题发生在哪一层。
网络排查可以按顺序进行：先看应用是否正常启动，再看容器端口是否监听，再看容器网络是否互通，再看宿主机防火墙和云安全组，最后看域名解析和反向代理。
一、先确认端口映射
端口映射是新手最容易混淆的地方。Compose里的ports通常写成宿主机端口:容器端口。访问外部服务时，用户访问的是宿主机端口；容器内部应用监听的是容器端口。两者写反，就会导致服务无法访问。
可以使用docker ps查看端口映射，也可以在宿主机上用curl测试本地端口。如果本地能访问、外网不能访问，问题可能在防火墙、安全组或云服务器面板。
二、容器之间如何互相访问
同一个Compose项目里的服务通常会在同一个默认网络中，可以用服务名互相访问。例如Web容器连接数据库时，主机名可以写数据库服务名，而不是写127.0.0.1。
127.0.0.1在容器里指的是容器自己，不是宿主机，也不是另一个容器。很多数据库连接失败，都是因为把主机名写成localhost。正确做法是使用服务名、容器名或明确的网络别名。
三、DNS和反向代理排查
如果容器能启动，端口也正常，但域名访问失败，就要检查DNS解析、反向代理和SSL配置。域名是否解析到正确服务器，Nginx或Caddy是否代理到正确端口，证书是否匹配域名，都会影响最终访问。
反向代理返回502时，通常说明代理服务器无法连接后端应用。此时要检查后端容器是否运行、端口是否正确、容器网络是否一致，以及应用是否只监听了127.0.0.1。
四、用最小路径定位问题
排查网络问题时，可以先在容器内部访问本服务，再从同一网络的其他容器访问，再从宿主机访问，最后从外网访问。每一步都能帮助判断问题边界。
如果容器内部访问正常，其他容器访问失败，可能是网络或服务名问题；宿主机访问失败，可能是端口映射问题；外网访问失败，则要看防火墙、安全组、域名和反向代理。
五、不要忽略IPv6和缓存
有些域名同时配置了IPv4和IPv6记录，如果服务器或反向代理没有正确支持IPv6，用户可能出现部分地区无法访问的情况。排查时要同时查看A记录和AAAA记录。
DNS缓存、浏览器缓存和CDN缓存也会干扰判断。修改解析或代理配置后，可以使用不同网络、无痕窗口或命令行工具测试，避免被旧缓存误导。
六、数据库连接失败怎么判断
应用提示数据库连接失败时，先确认数据库容器是否运行，再确认应用使用的主机名、端口、用户名和密码是否正确。Compose网络中通常应使用数据库服务名，而不是localhost。
如果配置都正确，再进入应用容器测试能否解析数据库服务名、能否连接数据库端口。这样可以区分是应用配置问题、网络问题还是数据库本身没有启动。
七、反向代理后的真实IP
使用Nginx、Caddy或CDN做反向代理时，应用看到的访问IP可能变成代理服务器IP。如果网站需要记录真实访客IP，需要正确配置转发头，并让应用信任对应代理。
配置不当会影响日志分析、限流、安全插件和后台登录保护。排查这类问题时，要同时看反向代理日志和应用日志。
八、排查结果要及时记录
网络问题往往涉及域名、代理、容器、端口、防火墙和云平台安全组。一次排查中改动过哪些配置、哪些测试通过、哪些测试失败，都应及时记录。
如果不记录，下一次出现同类问题时仍然要从头猜。简单记录一张表，包括测试位置、测试命令、结果和处理动作，就能明显提高后续排查效率。
