selinux拦截服务时表现为端口不通、403/500错误等，排查需分四步：先用getenforce/sestatus确认启用状态并临时禁用验证；再用ausearch和sealert分析avc拒绝日志；接着修复三类常见问题——文件标签错配、端口类型不匹配、布尔值未开启；最后才谨慎使用audit2allow生成自定义策略。
SELinux 拦截服务时，往往没有明显报错，只表现为端口不通、403/500 错误、服务无法启动或读写失败。排查核心不是“关不关”，而是“为什么拦”和“怎么准放”。
第一步：确认是不是 SELinux 在拦
别跳步，先验证根源：
- 运行 getenforce —— 若返回 Enforcing，说明策略正在生效；
- 运行 sestatus —— 看 “Current mode” 和 “Loaded policy name”，确认是 targeted 策略（默认）；
- 临时切宽容模式测试：setenforce 0，然后立刻重启服务或重试操作；若问题消失，基本锁定 SELinux；
- 切回强制模式：setenforce 1，避免长期处于 Permissive 影响安全审计。
第二步：看日志，定位具体被拒动作
拒绝记录在审计日志里，不是 /var/log/messages，也不是 journalctl 默认输出：
- 查最近 AVC 拒绝：ausearch -m avc -ts recent；
- 按进程名过滤（如 nginx）：ausearch -m avc -c nginx；
- 用 audit2why -a 解读每条拒绝——它会告诉你缺哪条 allow 规则，甚至建议 restorecon 或 setsebool；
- 更友好可读的报告：sealert -a /var/log/audit/audit.log（需已安装 setroubleshoot）。
第三步：常见拦截场景与对应修复
90% 的问题集中在三类上下文错配：
-
文件/目录标签错误：比如把网站文件放到 /data/www，但 SELinux 认为它不属于 httpd 可读区域。
→ 查标签：ls -Z /data/www；
→ 修复：semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"，再 restorecon -Rv /data/www； -
端口类型不匹配：httpd 监听 8080，但该端口没被标记为 http_port_t。
→ 查当前允许端口：semanage port -l | grep http_port_t；
→ 添加：semanage port -a -t http_port_t -p tcp 8080； -
布尔值未开启：比如需要 httpd 连外网（反向代理）、读用户家目录等。
→ 查相关开关：getsebool -a | grep httpd；
→ 临时开：setsebool httpd_can_network_connect on；
→ 永久开：setsebool -P httpd_can_network_connect on。
第四步：谨慎使用 audit2allow（仅当上述不适用）
这是兜底方案，不是首选。生成的规则要最小化、可审计：
- 收集本服务的拒绝事件：ausearch -c 'nginx' -m avc -ts today | audit2allow -M my-nginx；
- 生成两个文件：my-nginx.te（文本策略）和 my-nginx.pp（编译模块）；
- 装入系统：semodule -i my-nginx.pp；
- 验证后保留 .te 文件，便于日后复审或迁移。
