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 和端口：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 在 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
检查网络路径与系统级拦截
即使后端开着，中间仍可能被阻断：
- 执行
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
