1. 这不是网络问题是服务链路“断连”的明确信号当你在浏览器里输入一个域名或IP地址页面却弹出“xxx拒绝了我们的连接请求”——注意这不是模糊的“无法访问”或“连接超时”而是系统级明确反馈目标端主动拒收了本次TCP握手请求。这个提示背后绝非简单的DNS解析失败或防火墙拦截它直指服务架构中某个关键环节的“失联”状态。我做过上百个Web服务部署和故障排查每次看到这个报错第一反应不是去查网络通不通而是立刻打开终端执行telnet 目标IP 端口或nc -zv 目标IP 端口。如果返回Connection refused那基本可以锁定目标IP上对应端口根本没有进程在监听或者监听进程已崩溃、未启动、绑定地址错误。这和502 Bad Gateway有本质区别——502是上游比如Nginx成功连上了下游比如Tomcat但下游返回了异常响应而“拒绝连接”是上游根本连不上下游连建立TCP连接这第一步都失败了。常见组合场景非常典型你配置了Nginx反向代理到http://127.0.0.1:8080但Tomcat压根没起来或者它监听的是localhost:8080而非0.0.0.0:8080又或者Redis服务没启动应用尝试连接127.0.0.1:6379时直接被拒绝再比如Docker容器内Tomcat暴露了8080端口但宿主机上Nginx却试图去连容器的172.17.0.2:8080而该IP在宿主机路由表里根本不存在。这些都不是配置语法错误而是服务生命周期管理的断点。所以解决它的核心思路不是调参数、改配置而是逐层验证服务进程是否存活、是否监听正确地址与端口、网络路径是否可达。这篇文章不讲抽象理论只分享我在生产环境里用过的、能3分钟内定位根因的实操路径覆盖Nginx、Tomcat、Redis这三类高频组件的真实踩坑现场。2. 核心故障链路拆解从浏览器到后端服务的四层穿透逻辑要真正理解“拒绝连接”为何发生必须把一次HTTP请求在服务端的完整流转路径拆开来看。这不是单点故障而是一条由四层构成的依赖链任何一层断裂都会在最上层表现为“xxx拒绝了我们的连接请求”。我把它画成一条从左到右的流水线客户端 → Nginx反向代理层 → 应用服务器如Tomcat → 数据中间件如Redis。每一层都承担特定职责也埋着特定的“拒绝”雷区。2.1 第一层Nginx作为流量入口的“守门人”角色Nginx在这里不是最终服务者而是代理转发者。它的核心任务是接收用户请求根据location规则匹配后将请求通过proxy_pass指令转发给后端服务。关键点在于Nginx自身必须运行且其配置中指定的后端地址IP端口必须真实存在并可访问。例如配置文件里写proxy_pass http://127.0.0.1:8080;那么Nginx进程启动时并不会去检查8080端口有没有服务它只是忠实地执行转发动作。当用户请求到达Nginx尝试与127.0.0.1:8080建立TCP连接如果此时Tomcat没启动操作系统内核会直接返回Connection refusedNginx捕获到这个错误就会向上游返回502 Bad Gateway——但注意502是Nginx返回给用户的HTTP状态码而底层真正的错误日志里会清晰记录connect() failed (111: Connection refused) while connecting to upstream。这就是为什么你看到502时首先要怀疑的不是Nginx配置错而是它后面那个地址的服务挂了。我见过太多案例运维同学反复检查Nginx的upstream块、proxy_set_header却忘了systemctl status tomcat看一眼服务状态。Nginx本身很健壮它出问题的概率远低于它所代理的后端服务。2.2 第二层应用服务器Tomcat的“上岗”三要素Tomcat作为Java Web应用的容器要能被Nginx成功连接必须同时满足三个硬性条件进程存活、端口监听、绑定地址正确。缺一不可。首先“进程存活”是最基础的ps -ef | grep tomcat能查到java进程说明服务在跑但光有进程还不够。第二步是“端口监听”用netstat -tuln | grep :8080或ss -tuln | grep :8080确认8080端口确实在LISTEN状态。这里有个经典陷阱Tomcat默认配置server.xml中Connector的address属性是localhost这意味着它只监听127.0.0.1这个环回地址外部IP包括本机其他进程如Nginx无法访问。必须改成0.0.0.0或留空表示监听所有IPv4地址。第三步是“绑定地址正确”尤其在Docker或云服务器环境下Tomcat可能绑定在容器内部IP如172.17.0.2或私有网段IP如10.0.0.5而Nginx配置里写的却是公网IP或错误的内网IP自然连接被拒。我处理过一个线上事故开发在测试环境用127.0.0.1没问题上线后Nginx配置没改依然连127.0.0.1结果Nginx在宿主机上连自己的环回地址当然连不到容器里的Tomcat。2.3 第三层Redis等中间件的“静默失联”Redis作为内存数据库常被应用代码直接连接。当应用启动时会尝试初始化Redis连接池连接字符串通常是redis://127.0.0.1:6379。如果此时Redis服务未启动应用日志里会出现Cannot connect to Redis server或Connection refused而应用本身可能因为连接失败而启动不完全甚至直接退出。更隐蔽的情况是Redis服务起来了但配置了密码requirepass而应用连接时没带密码或者密码错误这时Redis会直接关闭连接表现也是Connection refused。另一个高频问题是端口冲突——比如你下载了Redis Windows版双击redis-server.exe启动默认监听6379但恰好本机已有其他程序占用了6379Redis启动失败却不报错进程一闪而过你以为它起来了其实根本没监听。这种情况下任何尝试连6379的请求都会被操作系统拒绝。Redis Desktop Manager这类可视化工具连不上往往就是这个原因。所以验证Redis不能只看进程是否存在更要redis-cli ping看是否返回PONG。2.4 第四层网络与防火墙的“隐形关卡”即使前三层都OK网络层也可能成为拦路虎。Linux系统默认的iptables或firewalld防火墙可能阻止了特定端口的入站连接。比如Tomcat监听8080但firewall-cmd --list-ports显示8080没开放外部请求会被防火墙丢弃而本地Nginx连127.0.0.1:8080是走环回接口不受影响但如果你的Nginx配置的是服务器公网IP如192.168.1.100:8080而防火墙没放行Nginx就会收到拒绝。另一个容易被忽略的点是SELinux在CentOS/RHEL系统上它可能阻止Nginx进程访问网络端口即使firewalld是关闭的。sestatus查看状态setenforce 0临时关闭可验证是否是它作祟。还有云服务器的安全组规则这是纯外部控制必须确保入方向规则放行了Nginx监听的端口如80/443和后端服务端口如8080/6379。我曾在一个阿里云ECS上折腾半天最后发现安全组里只开了80忘了开8080导致Nginx能访问但连不上Tomcat。3. 实操诊断四步法从现象到根因的精准定位面对“xxx拒绝了我们的连接请求”我总结了一套标准化的四步诊断流程每一步都有明确命令、预期输出和判断逻辑能在5分钟内锁定问题所在。这套方法不依赖日志堆砌而是用最基础的网络工具做正向验证直击要害。3.1 第一步确认Nginx自身状态与配置加载先排除Nginx这个“守门人”自身的问题。打开终端执行# 检查Nginx进程是否在运行 systemctl status nginx # 或者更直接地看进程 ps -ef | grep nginx如果状态是active (running)说明进程活着。接着验证配置文件语法是否正确避免因配置错误导致Nginx无法正常工作nginx -t这个命令会检查/etc/nginx/nginx.conf及所有include进来的子配置文件。如果输出nginx: configuration file /etc/nginx/nginx.conf test is successful说明语法无误。如果报错比如unknown directive proxy_pass那就是配置写错了需要修正。但请注意nginx -t成功不代表Nginx就能正常代理它只保证配置文件格式合法。接下来确认Nginx监听的端口是否正确# 查看Nginx监听了哪些端口 netstat -tuln | grep :80 # 或者用ss更快 ss -tuln | grep :80你应该看到类似tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN的行表示Nginx正在监听所有IP的80端口。如果这里没有输出说明Nginx根本没监听可能是启动失败或配置里listen指令写错了。这时候再看systemctl status nginx的详细日志通常会有bind() to 0.0.0.0:80 failed之类的错误意味着80端口被其他程序占用了比如Apache需要lsof -i :80找出占用进程并杀掉。3.2 第二步穿透Nginx直连后端服务端口假设Nginx一切正常现在要验证它要转发的目标——比如Tomcat的8080端口——是否真的“开门迎客”。不要依赖应用日志直接用网络工具探测# 尝试用telnet连接Tomcat端口需安装telnet telnet 127.0.0.1 8080 # 或者用ncnetcat更通用 nc -zv 127.0.0.1 8080如果返回Connected to 127.0.0.1或Connection to 127.0.0.1 8080 port [tcp/http-alt] succeeded!说明端口通服务在监听。如果返回Connection refused那就坐实了问题Tomcat没起来或者没监听这个地址端口。此时立刻去查Tomcat# 检查Tomcat进程 ps -ef | grep tomcat # 如果进程存在查它监听的端口 netstat -tuln | grep :8080 # 如果进程不存在尝试启动 ./tomcat/bin/startup.sh # Linux # 或 ./tomcat/bin/startup.bat # Windows启动后再次nc -zv 127.0.0.1 8080。如果还是Connection refused十有八九是server.xml里Connector的address没设对。打开conf/server.xml找到Connector port8080 ... /这一行确保它没有addresslocalhost这个属性或者将其改为address0.0.0.0。改完重启Tomcat。这个步骤我每天都要做几次因为开发同事经常忘记改这个配置就打包上线。3.3 第三步验证Redis等中间件的可用性如果后端服务Tomcat连通了但应用仍报错问题很可能出在Redis。同样不用看应用日志直接测Redis# 检查Redis进程 ps -ef | grep redis # 检查Redis监听端口 netstat -tuln | grep :6379 # 如果端口在监听用redis-cli测试连通性 redis-cli -h 127.0.0.1 -p 6379 ping如果返回PONG说明Redis服务健康。如果返回(error) NOAUTH Authentication required说明需要密码去redis.conf里找requirepass配置项然后用redis-cli -a your_password ping重试。如果返回Could not connect to Redis at 127.0.0.1:6379: Connection refused那就是Redis根本没启动。Windows下双击redis-server.exe有时会闪退建议用命令行启动redis-server.exe redis.windows.conf这样能看到错误输出。Linux下如果redis-server命令找不到说明没加到PATH用绝对路径/usr/local/bin/redis-server /etc/redis.conf。还有一个隐藏问题Redis的bind配置。默认bind 127.0.0.1只允许本地连接。如果应用和Redis不在同一台机器或者Docker网络模式不同需要改成bind 0.0.0.0并确保protected-mode no生产环境慎用需配合密码。3.4 第四步检查防火墙与安全组策略前三步都通但外部访问还是拒绝矛头指向网络策略。先查本地防火墙# CentOS 7/RHEL 7 firewall-cmd --state # 查看firewalld状态 firewall-cmd --list-ports # 查看开放端口 firewall-cmd --permanent --add-port8080/tcp # 如需开放8080 firewall-cmd --reload # Ubuntu/Debian ufw status verbose ufw allow 8080如果firewalld是running但8080没在列表里立即添加。再查SELinuxsestatus # 查看状态 # 如果是enforcing临时关闭测试 setenforce 0 # 测试后如确认是SELinux问题需永久设置 sed -i s/SELINUXenforcing/SELINUXpermissive/g /etc/selinux/config最后别忘了云服务商的安全组。登录阿里云/腾讯云控制台找到对应ECS实例进入“安全组”配置页检查入方向规则是否放行了你的服务端口。新手常犯的错误是只开了80和443给用户访问却忘了开8080给Nginx内部通信。安全组规则是独立于系统防火墙的必须两者都放行。我曾经帮一个客户排查折腾了两小时最后发现安全组里8080端口是灰色禁用状态点一下就解决了。4. 高频场景深度复盘NginxTomcatRedis组合的典型故障现场在实际项目中“拒绝连接”很少孤立出现往往是Nginx、Tomcat、Redis三者联动出问题。下面复盘三个我亲历的、最具代表性的故障场景每个都附带完整的排查过程、根因分析和修复方案全是血泪教训换来的经验。4.1 场景一Docker Compose环境下Nginx连不上Tomcat容器现象本地用Docker Compose启动Nginx和Tomcat浏览器访问域名显示“xxx拒绝了我们的连接请求”Nginx错误日志里connect() failed (111: Connection refused) while connecting to upstream。排查过程docker ps确认两个容器都在运行。docker exec -it nginx-container sh进入Nginx容器执行ping tomcat能通说明DNS解析OK。nc -zv tomcat 8080返回Connection refused问题在Tomcat容器内部。docker exec -it tomcat-container sh进入Tomcat容器netstat -tuln | grep :8080发现没有监听查/usr/local/tomcat/conf/server.xmlConnector配置为addresslocalhost。根因分析Docker容器内localhost指向容器自身但Tomcat默认只监听127.0.0.1而localhost在容器里解析为127.0.0.1看似合理。但问题在于Nginx容器要连Tomcat容器必须通过Docker网络桥接而localhost在Nginx容器里是它自己的环回地址不是Tomcat容器的地址。所以Nginx配置里proxy_pass http://tomcat:8080;是正确的但Tomcat必须监听0.0.0.0:8080才能被同网络的其他容器访问。addresslocalhost导致Tomcat只绑定了127.0.0.1对外不可见。修复方案修改Tomcat的server.xml将Connector port8080 protocolHTTP/1.1 addresslocalhost ... /中的addresslocalhost删除或改为address0.0.0.0。重启Tomcat容器docker restart tomcat-container。再次nc -zv tomcat 8080应返回success。经验心得Docker环境下任何服务要被其他容器访问监听地址必须是0.0.0.0这是铁律。localhost在容器里是“自己”不是“网络”。4.2 场景二Redis密码配置引发的连锁拒绝现象Spring Boot应用启动时报Cannot connect to Redis serverNginx访问前端页面时后端API返回502日志里Connection refused。排查过程redis-cli ping返回PONG说明Redis服务本身OK。ps -ef | grep java确认应用进程在跑。查应用配置文件application.ymlspring.redis.password为空。查redis.conf发现requirepass mySecretPass已启用。在应用服务器上手动用redis-cli -a mySecretPass ping返回PONG。根因分析Redis启用了密码认证但应用代码或配置里没提供密码。Redis在收到无密码的连接请求时会直接关闭socket操作系统返回Connection refused。这不是网络不通而是认证层面的拒绝。很多教程教你怎么装Redis却没强调requirepass这个配置的风险——一旦开启所有客户端必须带密码否则一律拒绝。修复方案方案A推荐在应用配置中补全密码。Spring Boot里spring.redis.passwordmySecretPass。方案B临时关闭密码仅测试环境注释掉redis.conf里的requirepass行重启Redisredis-server redis.conf。方案C使用Redis Desktop Manager连接时在连接设置里填入密码。经验心得Redis密码不是“锦上添花”而是“雪中送炭”的安全必需品。但配置密码后务必同步更新所有客户端连接字符串。我习惯在redis.conf里把requirepass行取消注释后立刻在旁边加一行注释# 注意所有客户端连接必须提供此密码提醒自己和团队。4.3 场景三云服务器安全组与本地防火墙双重拦截现象阿里云ECS上部署NginxTomcat本地浏览器访问公网IP显示“xxx拒绝了我们的连接请求”。curl http://公网IP同样失败。排查过程curl http://127.0.0.1成功说明Nginx在本地能访问。curl http://127.0.0.1:8080成功说明Tomcat在本地能访问。telnet 公网IP 80失败Connection refused。登录阿里云控制台查安全组规则发现只开放了80/4438080端口没开。开放8080端口后telnet 公网IP 8080成功但curl http://公网IP还是失败。查Nginx配置proxy_pass http://127.0.0.1:8080;没错。curl http://127.0.0.1:8080成功但curl http://公网IP失败说明问题在Nginx监听的端口。netstat -tuln | grep :80发现Nginx只监听127.0.0.1:80没监听0.0.0.0:80根因分析这是一个双重错误。第一重是云安全组没放行8080导致外部无法直连Tomcat第二重是Nginx配置里listen 80;没指定地址Nginx默认只监听127.0.0.1:80所以外部请求根本到不了Nginx。curl http://公网IP失败是因为Nginx没在公网IP上监听而不是Tomcat的问题。修复方案阿里云安全组添加入方向规则端口范围80/80授权对象0.0.0.0/0。Nginx配置修改/etc/nginx/nginx.conf或站点配置将listen 80;改为listen 0.0.0.0:80;或直接listen 80;Nginx 1.15默认监听所有地址但老版本需显式指定。nginx -t systemctl reload nginx。经验心得云服务器的网络是分层的安全组是第一道门系统防火墙是第二道服务监听地址是第三道。排查时必须按顺序逐层验证不能跳过任何一层。我给自己定的规矩是只要涉及公网访问第一件事就是登录云控制台截图保存当前安全组规则作为排查基线。5. 常见问题速查表与独家避坑指南在无数次救火过程中我整理了一份高频问题速查表按症状、可能原因、验证命令、解决方案四列组织方便快速对照。此外还总结了几条只有踩过坑才会懂的独家避坑指南这些都是文档里找不到的实战细节。症状可能原因验证命令解决方案telnet 127.0.0.1 8080返回Connection refusedTomcat进程未启动ps -ef | grep tomcat执行startup.sh启动Tomcat监听地址错误addresslocalhostnetstat -tuln | grep :8080修改server.xml删掉address属性或设为0.0.0.0重启Tomcat端口被占用lsof -i :8080kill -9 PID杀掉占用进程redis-cli ping返回Connection refusedRedis服务未启动ps -ef | grep redisredis-server /path/to/redis.conf启动Redis配置了bind 127.0.0.1且应用不在本地netstat -tuln | grep :6379修改redis.confbind 0.0.0.0protected-mode no重启Redis密码未配置redis-cli -a password ping在应用配置中添加密码或临时关闭requirepasscurl http://公网IP失败但curl http://127.0.0.1成功Nginx未监听公网IPnetstat -tuln | grep :80修改Nginx配置listen 0.0.0.0:80;重载云服务器安全组未开放80端口登录云控制台查看添加安全组规则放行80端口Nginx日志报upstream prematurely closed connection后端服务Tomcat/Redis响应超时或主动断连tail -f /var/log/nginx/error.log检查后端服务日志调大Nginxproxy_read_timeout独家避坑指南提示Nginx的proxy_pass末尾斜杠是魔鬼细节。proxy_pass http://127.0.0.1:8080;和proxy_pass http://127.0.0.1:8080/;行为完全不同。前者会将原始URI如/api/user原样转发后者会剥离location匹配的部分如location /api { proxy_pass http://.../; }则/api/user会变成/user转发。很多502错误其实是路径转发错误导致后端404Nginx误判为上游拒绝。务必根据你的location规则决定proxy_pass要不要加斜杠。注意Tomcat的shutdown.sh不一定能正常关闭进程。有时候ps -ef \| grep tomcat还能看到java进程但端口已经释放。这是因为Tomcat的优雅关闭机制可能卡住。我的做法是先./shutdown.sh等10秒如果netstat -tuln \| grep :8080还显示监听就pkill -f tomcat强制杀掉再启动。这比等它自己退出快得多。警告Redis的maxmemory配置不是万能的。当内存达到上限Redis会根据maxmemory-policy策略淘汰key。但如果策略是noeviction默认内存满时新写入会直接失败应用连接可能被拒绝。线上环境务必设置合理的maxmemory和maxmemory-policy比如allkeys-lru并监控used_memory指标。经验用curl -v http://your-domain代替浏览器访问。-v参数会显示完整的HTTP请求响应过程包括TCP连接阶段。如果看到* Connected to your-domain (xxx.xxx.xxx.xxx) port 80 (#0)说明TCP连接成功如果卡在* Trying xxx.xxx.xxx.xxx:80...然后超时那就是网络层问题。这个命令比刷新浏览器快十倍是定位的第一利器。心得养成“配置即文档”的习惯。每次修改nginx.conf、server.xml、redis.conf都在文件顶部加注释写明修改日期、原因、操作人。比如# 2024-06-15 by zhangsan: 修复Docker网络问题将address从localhost改为0.0.0.0。半年后故障复盘这行注释能帮你省下2小时。最后再分享一个小技巧我把上面四步诊断法写成了一个Shell脚本check-service.sh放在服务器上。它会自动执行systemctl status nginx、nc -zv 127.0.0.1 8080、redis-cli ping等命令并汇总输出结果。新同事入职我第一件事就是教他运行这个脚本而不是翻日志。技术的本质是让复杂变简单而不是让简单变复杂。