Nginx 连接 TCP 后端报 Permission denied：检查 SELinux 拒绝记录

后端端口直接访问正常，经过 Nginx 却失败，错误日志出现 connect() failed (13: Permission denied) while connecting to upstream。在启用 SELinux 的 RHEL 9 或类似策略环境中，应检查是否有对应的网络连接拒绝记录。后端能被浏览器或普通 shell 访问，不代表受限制的 Nginx 进程也有同样权限。

本文针对 Nginx 到 TCP 后端的连接。Unix socket 文件权限、Nginx 读取静态文件失败以及 Connection refused 属于不同场景，不能直接套用网络连接布尔值。

用同一次请求对应日志和审计记录

先记下请求时间、Nginx 日志中的后端地址与端口，再检查系统状态。以下命令只供读者在实际服务器上检查：

getenforce
getsebool httpd_can_network_connect
sudo ausearch -m AVC,USER_AVC -ts recent

recent 查最近十分钟的审计记录。若故障更早，使用适合实际发生时间的查询范围；没有命中记录也可能是时间不对、审计采集缺失或拒绝被抑制，不能据此确认不存在 SELinux 影响。

关注同一次请求关联的进程、源安全上下文、目标端口和拒绝动作。例如 Nginx 进程处于 httpd_t 域，记录拒绝 tcp_socket 的 name_connect，且端口与失败后端一致，才支持继续检查对应网络连接策略。这里列的是判断字段，不是每台机器都会出现的固定输出。

SELinux 为 Disabled 时，这条路径不适用。为 Permissive 时，通常会记录而不执行阻断，应继续寻找真实阻断层。没有对应网络拒绝时，还要检查服务沙箱、其他安全模块、网络策略及实际后端地址，不能只看到数字 13 就开启权限。

确认策略需要后，再调整布尔值

RHEL 9 的 Nginx 反向代理配置使用 httpd_can_network_connect 允许相应域发起网络连接。但它不是仅允许某个站点或某一个后端端口的规则，可能同时影响处于同一策略域的其他 Web 服务。自定义策略或不同发行版需要核对自己的域和规则。

记录修改前的布尔值与持久配置，由有权限的管理员确认这项网络访问符合部署要求。仅临时验证时，可以使用：

sudo setsebool httpd_can_network_connect on

不加 -P 的改动通常不会在重启后保留。确认需要长期启用并完成授权后，使用：

sudo setsebool -P httpd_can_network_connect on

-P 会写入持久策略设置，操作可能需要等待。不要把两个命令无条件连续运行，更不要在没有审计依据时为了“排除干扰”关闭整个 SELinux。若布尔值原本已经开启，重复开启没有诊断价值，应继续检查拒绝涉及的域、类型和具体权限。

直接生成并加载任意放行策略，也容易把路径或标签错误永久掩盖。已有策略不能满足实际最小权限需求时，应由管理员根据对应拒绝记录设计规则，而不是照搬另一台机器的模块。

后端连接恢复后，重新看业务响应

修复后重新发起同类请求：对应的网络连接拒绝应不再阻断，Nginx 能连接预期后端，业务响应符合要求。仅让错误页改变还不够。

如果随后返回 400，并出现请求头或 Cookie 过大等信息，说明已经进入另一层请求处理，应按新日志检查头部限制和应用行为。不要为了第二个错误继续扩大 SELinux 权限。

需要恢复时，按修改前记录还原临时值和持久值。若原来是开启状态，就不能为了回退随意关闭。持久回退同样可能影响其他受该布尔值控制的服务，应在确认影响后进行。