Apache mod_proxy连接后端被拒绝本质是TCP层连接失败，错误日志表现为“Connection refused”，模块标识为[proxy:error]或[proxy_http:error]，需优先验证网络通路、后端监听状态和代理配置一致性。

apache mod_proxy 连接后端被拒绝，本质是 tcp 层连接失败，错误日志中通常表现为 connection refused，对应模块标识为 [proxy:error] 或 [proxy_http:error]。这不是响应异常，而是根本没连上——需优先验证网络通路、后端监听状态和代理配置三者是否一致。

看 error_log 中明确的连接拒绝线索

打开 Apache 错误日志（/var/log/apache2/error.log 或 /var/log/httpd/error_log），搜索以下关键词：

• AH00957: HTTP: attempt to connect to [IP:PORT] failed → Apache 尝试建立 TCP 连接但被操作系统直接拒绝，常见于后端未启动、端口错配或防火墙拦截
• Connection refused（无 AH 编号）→ 底层 socket connect() 系统调用返回 ECONNREFUSED，说明目标地址确有监听进程，但拒绝了当前连接请求
• No route to host 或 Network is unreachable → 网络路由不通，可能是网关缺失、跨网段未配置路由，或容器/云环境安全组未放行出向流量

确认后端服务真实运行且监听正确地址

不能只信“服务已启动”，要验证它是否真在监听你配置的 IP 和端口：

• 在 Apache 所在服务器上执行：ss -tuln | grep :8080（把 8080 换成你的后端端口），确认有 LISTEN 状态且监听地址不是 127.0.0.1:8080（若后端只绑本地回环，而 Apache 用公网 IP 代理就会被拒）
• 用 curl -v http://127.0.0.1:8080/health 直连测试：如果也报 Connection refused，说明后端根本没起来；如果成功，则问题出在 Apache 配置的地址与实际监听地址不一致
• 检查后端是否绑定到了 0.0.0.0（全网卡）或具体内网 IP，而非仅 127.0.0.1

检查网络路径与系统级拦截

即使后端开着，中间仍可能被阻断：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 执行 telnet 192.168.1.20 8080（替换为目标 IP 和端口）：若提示 Connection refused，说明连接未达后端；若超时或无法解析，则是网络或 DNS 问题
• 检查防火墙：sudo ufw status（Ubuntu）或 sudo iptables -L -n -v（CentOS），确认出向规则允许访问后端端口
• 云环境必须检查安全组/网络 ACL：不仅要看入方向是否开放，还要确保 Apache 所在机器的出方向能访问后端端口（很多云平台默认限制出向）
• SELinux（RHEL/CentOS）：运行 getsebool httpd_can_network_connect，若为 off，执行 setsebool -P httpd_can_network_connect 1

核对 ProxyPass 配置与协议细节

一个字母写错就可能导致连接发往错误目标：

• 确认 ProxyPass 地址中的协议是 http:// 还是 https://；若后端是 HTTP 却写了 HTTPS，Apache 会尝试 TLS 握手，最终因无响应而超时或拒绝
• 检查域名解析：若用域名（如 ProxyPass http://backend-api:8080/），确认该域名在 Apache 主机上能正确解析（nslookup backend-api），否则解析失败也会表现为 Connection refused
• 避免多余斜杠或路径拼接错误，例如 ProxyPass /api/ http://127.0.0.1:8080/api/ 和 ProxyPass /api/ http://127.0.0.1:8080/ 行为不同，后者可能触发后端 404，但不会导致 Connection refused