selinux拦截本质是策略拒绝而非权限不足，排错须按“确认→定位→修复”三步：先用getenforce/sestatus验证模式，再通过ausearch/audit2why/sealert分析avc日志，最后针对文件标签、端口类型或布尔值错误修复，audit2allow仅作兜底。
SELinux 拦截导致的权限报错，表面看是“Permission denied”或“Operation not permitted”，但实际不是传统文件权限（DAC）问题——ls -l 显示权限正确、用户属主无误，照样被拦。关键在日志里找 avc: denied 记录，再比对进程域类型和目标对象类型是否被策略允许。
确认 SELinux 是否生效
别跳过这步，很多排查失败是因为没确认根源：
- 运行
getenforce：返回Enforcing才说明策略正在起作用 - 运行
sestatus：检查 “Current mode” 是否为enforcing，“Loaded policy name” 是否为targeted - 临时切宽容模式验证：
sudo setenforce 0，重试出错操作；若问题消失，基本锁定 SELinux - 验证完立刻切回：
sudo setenforce 1，避免审计日志丢失
抓取并解读 AVC 拒绝日志
拒绝记录不在 /var/log/messages 或默认 journalctl 输出里，必须查审计日志：
- 查最近所有拒绝：
ausearch -m avc -ts recent - 按服务名过滤（如 httpd）：
ausearch -m avc -c httpd - 用
audit2why -a解读每条记录：它会指出缺哪条allow规则，并建议restorecon或setsebool - 更易读的汇总报告（需安装
setroubleshoot）：sealert -a /var/log/audit/audit.log
定位具体拦截点：看上下文是否匹配
90% 的问题源于三类上下文错配，要分别查清进程和目标的类型：
-
查进程真实域类型：用
ps -Z -C nginx（替换为你的服务名），重点看第二字段如system_r:httpd_t:s0中的httpd_t -
查文件/目录类型：用
ls -Z /path/to/file（文件）或ls -Zd /path/to/dir（目录自身），第三段如default_t或httpd_sys_content_t就是关键类型 -
查端口类型：如 MySQL 改用 3307 端口，运行
semanage port -l | grep mysql，确认该端口是否标记为mysqld_port_t
针对性修复，不靠 audit2allow 盲加规则
优先用标准方法修复上下文或配置，audit2allow 是兜底手段：
-
文件/目录标签错误：比如网站文件放在
/data/www却是default_t，应改为httpd_sys_content_t→ 先注册规则：sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"，再批量重标：sudo restorecon -Rv /data/www -
端口未授权：如 Nginx 监听 8080 →
sudo semanage port -a -t http_port_t -p tcp 8080 -
布尔值未开启：如 httpd 需连外网 →
sudo setsebool -P httpd_can_network_connect on
