“Connection refused”表示Apache作为客户端连接后端时，目标端口无进程监听或被策略拒绝，属TCP层连接建立失败；需优先验证后端服务是否运行、正确监听端口（如ss -tuln | grep :8080）、绑定地址是否匹配（如0.0.0.0而非仅127.0.0.1），并排查防火墙、SELinux、代理配置错误及DNS解析问题。
“connection refused” 表示 apache 作为客户端尝试连接后端服务时，目标地址的端口上没有进程在监听，或被系统/网络策略主动拒绝。这不是超时或重置，而是 tcp 层的 syn 包发出后收到 rst 或直接无响应——说明连接根本没建立成功。
确认后端服务是否真实运行并监听对应端口
这是首要验证点。Apache 无法连上，往往是因为后端压根没起来、端口不对、或绑定错了地址：
- 在 Apache 所在服务器上执行：
ss -tuln | grep :8080（把 8080 换成你 ProxyPass 中的实际端口），看是否有LISTEN状态且监听127.0.0.1:8080或*:8080 - 检查后端服务状态：
systemctl is-active tomcat9、journalctl -u nginx -n 20，或查看其日志中是否有启动失败、端口占用、配置错误等信息 - 注意绑定地址：很多后端默认只监听
127.0.0.1，若 Apache 通过内网 IP（如10.0.1.5）去连，就会被拒；应确保后端监听0.0.0.0或具体可路由地址
检查网络连通性与中间拦截
即使后端开着，也可能被防火墙、安全组或 SELinux 拦在半路：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 用
telnet 127.0.0.1 8080或nc -zv 127.0.0.1 8080直连测试。如果本机都连不上，基本确定是后端或本地策略问题 - 检查 iptables/nftables：
iptables -L -n -v | grep 8080，确认 OUTPUT 链未 DROP 出向连接；云环境要查安全组是否放行 Apache 主机 → 后端 IP 的出方向流量（不止入方向） - CentOS/RHEL 系统默认启用 SELinux，会阻止 httpd 进程发起 outbound 连接：运行
getsebool httpd_can_network_connect，若为off，执行setsebool -P httpd_can_network_connect 1
核对 Apache 代理配置是否写错
看似简单，但拼写错误、协议混淆、路径多余斜杠等问题高频导致“拒绝”：
- 检查
ProxyPass地址是否完整准确，例如：ProxyPass /app http://127.0.0.1:8080/app中两端路径需一致；多写一个/（如http://127.0.0.1:8080//）可能触发后端拒绝 - HTTPS 后端必须用
https://协议，并加载mod_ssl，同时配置SSLProxyVerify none和SSLProxyCheckPeerCN off（开发环境）绕过证书校验，否则握手失败也会表现为连接拒绝 - 避免使用变量或未解析的主机名：
ProxyPass / http://backend-service:8080/中backend-service若 DNS 不通或 hosts 未配，解析失败也会报 Connection refused
查看 Apache 错误日志定位具体失败点
错误日志里不会只写“connection refused”，而是带上下文的关键线索：
- 搜索关键词：
Connection refused、attempt to connect to、failed，典型日志形如：[proxy:error] [pid 12345] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8080 failed - 注意日志中的 PID 和时间戳，结合同一时刻的后端日志、系统日志（
dmesg或/var/log/messages）交叉判断是否发生 OOM Killer 杀进程、端口被抢占等情况 - 若日志中反复出现同一后端地址的拒绝，而其他后端正常，基本可锁定该后端自身问题，而非 Apache 配置
