基于Jenkinsfile部署Web应用Docker容器时端口80连接拒绝问题

遇到这种web_test容器能解析到自身IP但80端口连不上的情况，我帮你梳理几个最常见的排查方向——都是我平时部署容器时踩过的坑，应该能快速定位问题：

1. 先确认容器内的Web服务真的在监听80端口 #

这是最核心的第一步，毕竟如果服务根本没起来或者没监听80，怎么连都白搭。你可以进入web_test容器，执行这两个命令检查端口监听状态：

# 用netstat（如果容器里预装了）
netstat -tulpn | grep :80
# 或者用更通用的ss命令
ss -tulpn | grep :80

如果没有任何输出，直接看服务日志找原因：

# 宿主机上查看容器整体运行日志
docker logs web_test
# 或者容器内直接查看Web服务的专属日志，比如Nginx的错误日志
cat /var/log/nginx/error.log

大概率是服务启动失败（比如配置文件语法错误、依赖包缺失），或者服务默认监听的是其他端口（比如8080）。

2. 检查Web服务的绑定地址 #

很多新手容易踩这个坑：Web服务默认只绑定127.0.0.1（本地回环地址），这时候用容器的外部IP（比如172.18.0.6）访问就会被拒绝，因为服务只接受localhost的请求。

比如Nginx的配置里，listen指令要确保是listen 0.0.0.0:80;，而不是listen 127.0.0.1:80;。你可以进入容器检查配置：

# 检查Nginx主配置文件
cat /etc/nginx/nginx.conf | grep listen
# 或者站点专属配置文件
cat /etc/nginx/sites-available/default | grep listen

如果是绑定了127.0.0.1，改成0.0.0.0:80后重启服务，再测试应该就好了。

3. 确认Jenkinsfile里的容器启动逻辑 #

如果你的web_test容器依赖其他服务（比如数据库、缓存），Jenkinsfile可能启动容器后立刻跑Codeception测试，这时候Web服务还没完全初始化就绪，自然连不上。

这种情况可以在测试前加个等待逻辑，比如：

# 在Jenkinsfile的测试步骤前添加循环等待
sh 'until curl -s -f http://web_test:80; do echo "Waiting for web service ready..."; sleep 2; done'

用curl -f的话，只有服务成功返回才会退出循环，避免误判服务状态。

4. 检查Docker容器的端口配置（辅助排查） #

你是在容器内部访问自身，所以宿主机的端口映射（-p 80:80）不影响，但可以确认下容器内部的服务端口配置是否正确。比如用docker inspect查看容器的暴露端口：

docker inspect web_test | grep -A 5 "ExposedPorts"

如果ExposedPorts里没有80/tcp，要么是Dockerfile没写EXPOSE 80，要么启动时没指定，但这其实不影响服务启动，只是元数据的问题，核心还是服务本身的监听状态。

最可能的几个结论（按优先级） #

• Web服务未启动或启动失败（看日志就能快速定位）
• Web服务只绑定了127.0.0.1，未监听所有网卡
• 服务监听的不是80端口（比如默认用了8080）
• 测试执行过早，Web服务还没完成初始化

先从第一步检查端口监听开始，应该能很快找到问题所在。

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