Fix Nginx proxy blocked by SELinux on Rocky Linux 9

2026-10-19·Rocky Linux 9 · per RHEL 9 SELinux documentation · 2026-10·6 steps

Tell whether a 502 and a Permission denied in error.log come from SELinux, fix it with a boolean, and label a custom document root.

If Nginx is configured correctly but the proxy returns 502, suspect SELinux. This assumes the app is listening normally on 127.0.0.1:8080. For the proxy configuration itself, see the Ubuntu 24.04 reverse proxy guide.

[1] Confirm the symptom. The browser shows 502 Bad Gateway, and /var/log/nginx/error.log contains this message.

console

# tail -n 5 /var/log/nginx/error.log

output

connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream

If the same place shows (111: Connection refused), the app is down and SELinux is not the cause. This guide covers (13: Permission denied).

[2] Check the SELinux mode. In Enforcing mode, policy violations are actually blocked.

console

# getenforce

[3] Find the denial (AVC). This is the command the official documentation uses. If nothing is returned, check that auditd is running, repeat the blocked action, and search again.

console

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

How to read it: the { ... } part is the denied action, comm is the process, and the third field of scontext and tcontext is the source and target type (the documentation's httpd example has scontext=...:httpd_t:s0). For this symptom, expect comm="nginx", httpd_t in scontext, and the action name_connect. The actual line differs per server, so check it yourself.

[4] Turn on the httpd_can_network_connect boolean. -P keeps it across reboots.

console

# setsebool -P httpd_can_network_connect 1# getsebool httpd_can_network_connect

[5] If the document root is not in a default location such as /srv/site, wrong file labels can cause 403. Give the new path the same rule as /var/www. The official documentation shows -e to make a path equivalent to a default one.

console

# semanage fcontext -a -e /var/www /srv/site# restorecon -Rv /srv/site

semanage fcontext only registers the rule; restorecon changes the actual file labels. In the documentation's example the output includes Relabeled ... to ...httpd_sys_content_t:s0 lines.

[6] Verify the fix. Send the same request again and check that no new (13: Permission denied) appears in error.log.

console

# curl -sI http://127.0.0.1/ | head -n 1

setenforce 0 (permissive) makes the symptom disappear, but it is not a fix: it turns SELinux enforcement off. Use it once to confirm the cause, then revert with setenforce 1.

Tested on: not run on Rocky Linux. Commands come from the documents above (semanage fcontext, restorecon, ausearch); the exact form of setsebool -P httpd_can_network_connect and of the name_connect denial line rests on the RHEL documentation's description and general behavior, not on a run here. The error.log text is an example of the symptom.

Analyze your Nginx log in the browser ↗ — nothing is uploaded.

#selinux#nginx#rocky

Fix Nginx proxy blocked by SELinux on Rocky Linux 9

Related manuals