.NET Core Docker容器Web API绑定localhost连接拒绝问题咨询

容器内部的localhost指向容器自身的环回接口，仅允许容器内部进程访问，宿主机端口转发、其他容器发送的流量都会走容器的桥接网卡，服务如果仅绑定localhost，就不会响应桥接网卡收到的请求，自然会报连接拒绝。

两个服务表现不一致的核心原因是ASP.NET Core的配置优先级不同：ASP.NET Core配置的生效优先级为命令行参数 > 环境变量 > 配置文件 > 代码硬编码默认值：

• 你的Web API没有在代码、配置文件中覆盖监听地址，所以ASPNETCORE_URLS=http://localhost的环境变量直接生效，仅监听环回接口，外部无法访问；改为http://0.0.0.0后监听所有网卡，就能正常响应端口转发的请求。
• 你的Web应用大概率在代码（Program.cs/Startup.cs的Kestrel配置段）或者镜像内置配置中硬编码了监听所有网卡，该配置优先级高于环境变量中的localhost设置，所以哪怕环境变量写了绑定localhost，实际还是监听所有网卡，自然可以正常访问。

你可以直接进入两个容器执行ss -tunlp查看监听地址，就能验证两个服务实际的监听差异。

你可以通过以下几种方式逐层排查通信链路：

• 宿主机层面抓包：使用Wireshark抓宿主机对应网卡的流量，过滤条件设置为tcp.port == 目标端口，就能看到浏览器发出的请求、Docker网桥转发的全流程报文。
• Docker网桥层面抓包：你使用的是自定义bridge网络doc_manager，先通过docker network inspect doc_manager查到网桥ID，再用tcpdump -i br-<网桥ID> port 80直接抓网桥层面的流量，排查转发是否正常。
• 容器内部抓包：如果容器镜像内置了tcpdump等工具，可以直接docker exec进入容器，抓对应网卡的流量，确认请求是否真的到达容器内部。
• 应用日志排查：将ASP.NET Core的日志级别调整为Debug，就能在容器日志中看到Kestrel的监听地址、收到的所有请求明细，直接判断请求是否被服务接收。

内容的提问来源于stack exchange，提问作者Ricardo