selinux拦截导致403/500错误或端口不通时，应先用getenforce和sestatus确认enforcing模式，再通过setenforce 0临时验证；接着用ausearch和sealert分析avc拒绝日志，重点修复文件标签错配、端口类型不匹配、布尔值未开启三类问题，慎用audit2allow。
Web 服务在 Linux 上突然返回 403、500 错误，或端口完全不通，但文件权限、防火墙、服务进程都正常？很可能是 SELinux 在拦截。排查关键不是“关不关”，而是“拦了什么”和“怎么准放”。
确认 SELinux 是否正在生效
别跳步，先验证是不是它在作怪：
- 运行 getenforce —— 若输出 Enforcing，说明策略已强制执行
- 运行 sestatus —— 看 “Current mode” 是否为 enforcing，“Loaded policy name” 是否为 targeted（默认）
- 临时切到宽容模式验证：setenforce 0，然后立刻重启服务或重试访问；若问题消失，基本锁定 SELinux
- 验证后立即切回：setenforce 1，避免长期处于 Permissive 影响审计完整性
查日志，定位被拒的具体动作
SELinux 的拒绝记录不在常规日志里，而在审计日志中：
- 查最近的 AVC 拒绝：ausearch -m avc -ts recent
- 按 Web 进程过滤（如 nginx 或 httpd）：ausearch -m avc -c nginx 或 ausearch -m avc -c httpd
- 用 audit2why -a 解读每条拒绝——它会说明缺哪条 allow 规则，并提示是否该用 restorecon 或 setsebool
- 更直观的分析报告：sealert -a /var/log/audit/audit.log（需已安装 setroubleshoot）
修复三类高频拦截问题
90% 的 Web 访问失败源于上下文错配：
-
文件标签错误：比如把网站文件放到 /data/www，但标签仍是 default_t 而非 httpd_sys_content_t
→ 查当前标签：ls -Z /data/www
→ 修复：semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"，再执行 restorecon -Rv /data/www -
端口类型不匹配：Web 服务监听 8080，但该端口未被标记为 http_port_t
→ 查允许端口：semanage port -l | grep http_port_t
→ 添加支持：semanage port -a -t http_port_t -p tcp 8080 -
布尔值未开启：例如需要反向代理连外网、读取用户家目录等
→ 查相关开关：getsebool -a | grep httpd
→ 临时启用：setsebool httpd_can_network_connect on
→ 永久生效：setsebool -P httpd_can_network_connect on
慎用 audit2allow，优先走标准修复路径
audit2allow 生成自定义策略是最后手段。它绕过策略设计逻辑，容易引入安全盲区。只有在确认行为合理、且上述三类方法都不适用时才考虑：
- 提取规则：ausearch -m avc -c httpd | audit2allow -M myhttpd
- 加载模块：semodule -i myhttpd.pp
- 务必配合测试与审计审查，避免策略泛化
