容器化Java应用curl访问localhost正常 同地址运行测试用例行为异常

1. 排查请求链路差异 #

• 对比curl命令与测试用例的全量请求信息：校验请求方法、请求头、参数编码、请求体格式是否完全一致。多数测试框架会默认携带Content-Type: application/json、额外Cookie或自定义User-Agent头，与手动执行的curl请求存在差异。可在Java应用中开启全量访问日志，打印所有请求头、参数与请求体，直接对比两侧请求的区别。
• 验证localhost解析规则：部分系统或测试框架会默认将localhost解析为IPv6地址::1，若Docker端口仅绑定了IPv4的0.0.0.0:8085，会导致请求路由异常。可临时将测试用例的基础URL替换为127.0.0.1:8085验证是否为解析问题。

2. 排查Docker与端口占用问题 #

• 确认端口映射唯一：执行docker ps | grep 8085查看是否仅有目标Java应用容器绑定了8085端口，避免本地存在旧容器实例、其他进程占用该端口，导致测试请求被转发到错误的服务实例。
• 确认测试用例运行环境：若测试用例运行在独立的Docker容器中（如容器化集成测试），容器内的localhost指向测试容器本身，无法访问宿主暴露的8085端口。可将测试容器与Java应用、配套服务加入同一个Docker Compose网络，通过服务名访问Java应用，或替换基础URL为宿主的局域网IP。

3. 排查应用与配套服务逻辑 #

• 校验应用是否存在来源判断逻辑：部分应用会配置跨域校验、限流规则、User-Agent拦截逻辑，对不同来源的请求返回不同结果。可在接口入口处打印请求来源IP、请求头信息，定位是否存在特殊拦截规则。
• 确认配套服务连通性：若测试用例包含写入操作，需验证Java应用容器与dynamo、kafka等配套服务的网络连通性。手动curl仅触发查询逻辑时可能命中本地缓存，不会暴露配套服务的连接异常，写入操作触发连接错误时会出现不一致的返回结果。

内容的提问来源于stack exchange，提问作者N.Rajal