SELinux阻止httpd或nginx访问自定义目录的五大常见原因及修复：一是目录上下文未设为httpd_sys_content_t；二是忽略avc拒绝日志而误判为配置问题；三是非标准端口未用semanage添加到http_port_t；四是CGI/PHP/socket相关布尔值或上下文缺失；五是禁用SELinux掩盖问题，应使用audit2allow生成最小策略模块。
SELinux 阻止 httpd 或 nginx 访问自定义目录，通常不是权限设错了，而是上下文或策略没对上。 它不看传统 Linux 权限（如 chmod/chown），而是额外检查进程和文件的 SELinux 上下文是否匹配。下面这 5 种情况最常被忽略，且修复方式明确、可验证。
误区一：目录没有正确设置 SELinux 文件上下文
即使 chmod 755、chown apache:apache（或 nginx:nginx）全对，SELinux 仍会拒绝访问——因为文件默认继承父目录上下文，而 /var/www/html 外的路径（比如 /srv/myapp）往往仍是 default_t 或 unconfined_u:object_r:usr_t:s0，不被 httpd_t 允许读取。
- 查当前上下文：
ls -Z /srv/myapp - 临时修复（重启后失效）：
chcon -t httpd_sys_content_t /srv/myapp - 永久生效（推荐）：
semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?"，再运行restorecon -Rv /srv/myapp
误区二：启用了 require_secure_transport 或其他模块限制，但 SELinux 拦截在前
很多人先查 nginx error.log 或 Apache 的 access_log，看到 “Permission denied” 就以为是配置问题，其实 SELinux 的 avc: denied 日志早就在 /var/log/audit/audit.log 或 journalctl -t setroubleshoot 里报过了。SELinux 拦截发生在系统调用层，比 Web 服务器逻辑更早。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 实时抓拒绝记录：
ausearch -m avc -ts recent | audit2why - 或直接看解释：
journalctl -t setroubleshoot | grep -A 10 "httpd\|nginx" - 别跳过这步——90% 的“配置无效”其实是 SELinux 先拦住了
误区三：用了非标准端口，但 SELinux 没放行该端口类型
比如把 nginx 绑定到 8080，或 httpd 改成监听 8000，SELinux 默认只允许 http_port_t 绑定在 80、443、8008、8080（部分版本）。若你用的是 8081 或 9000，进程启动时会被拒绝 bind()，日志里显示 “cannot bind to port”，但真正原因是 SELinux 策略未授权。
- 查当前允许的 HTTP 端口：
semanage port -l | grep http_port_t - 添加自定义端口：
semanage port -a -t http_port_t -p tcp 8081 - 删错可回退：
semanage port -d -t http_port_t -p tcp 8081
误区四：启用了 cgi、php-fpm、proxy_pass，但没配对应上下文或布尔值
静态文件访问可能通了，但一跑 PHP 脚本就 500，或者 proxy_pass 到本地 socket 报 “Connection refused”——常见于没开必要布尔开关，或 socket 文件上下文不对（比如 /var/run/php-fpm.sock 是 var_run_t，但 httpd_t 默认不能 connectto 它）。
- 启用 CGI 执行：
setsebool -P httpd_can_network_connect 1 - 允许连接 Unix socket：
setsebool -P httpd_can_connect_unix 1 - 若用 php-fpm + socket，确保 socket 文件上下文为 httpd_var_run_t：
chcon -t httpd_var_run_t /var/run/php-fpm.sock
误区五：禁用 SELinux 后问题消失，就以为“关掉就行”，结果上线后出问题
开发环境关 SELinux 图省事，但生产环境通常强制开启。临时 disable（setenforce 0）只是掩盖问题，不是解决。更危险的是修改 /etc/selinux/config 设为 disabled —— 这会导致系统失去 MLS/MCS 隔离能力，且某些云平台（如 RHEL on AWS）策略要求 enforcing=1。
- 正确做法：保持
SELINUX=enforcing，用audit2allow生成最小策略模块 - 例如收集拒绝日志后：
ausearch -m avc -ts today | audit2allow -M myhttpd，再semodule -i myhttpd.pp - 策略模块名要具体（如 mynginx_static），避免泛化影响安全边界
