Permissive模式下SELinux仅记录avc日志而不拦截操作，服务被拒必因防火墙、服务状态、端口监听或配置权限问题，与SELinux强制执行无关。
当 getenforce 显示 Permissive，说明 SELinux 当前处于“宽容模式”——即策略仍在加载并记录拒绝日志（avc: denied），但**不会实际阻止任何操作**。因此，如果服务仍被拒绝，问题几乎一定不在 SELinux 的强制执行层面，而是其他机制在起作用。
确认 SELinux 确实未拦截（排除误判）
Permissive 模式下，SELinux 不会返回 EACCES 或 EPERM 给应用，所以服务收到的“拒绝”必然来自其他地方。可快速验证：
- 检查
/var/log/audit/audit.log或dmesg | grep avc：若有avc: denied日志，说明 SELinux 策略本应拒绝，但因是 Permissive 模式而放行了——此时服务报错不是 SELinux 导致的 - 临时切换为
Disabled（setenforce 0已是 Permissive；需改/etc/selinux/config并重启或用kernel parameter selinux=0）再测试：若行为不变，彻底排除 SELinux
重点排查真实拦截源：firewalld / iptables
最常见干扰项是防火墙。Permissive 模式对网络访问完全无影响，端口不通、连接被拒通常源于此：
- 运行
firewall-cmd --list-all查看当前 zone 开放的端口和服务 - 确认服务端口（如 8080、22、5432）是否在
public或对应 zone 中显式允许；未开放则连接会被直接丢弃，现象就是“连接被拒绝”（Connection refused是服务未监听，No route to host或超时才更倾向防火墙） - 临时停用防火墙测试：
systemctl stop firewalld（RHEL/CentOS/Fedora）或ufw disable（Ubuntu）
检查服务自身状态与监听配置
SELinux Permissive 下，服务能否启动、是否绑定端口、是否限制本地访问，全由服务自身和系统权限控制：
- 用
systemctl status your-service确认服务进程是否真正 running，而非 failed 或 activating - 用
ss -tlnp | grep :端口号或netstat -tulpn | grep :端口验证服务是否在监听，注意127.0.0.1:端口表示仅本地可连，*:端口或:::端口才接受外部连接 - 检查服务配置文件（如 Nginx 的
listen、PostgreSQL 的postgresql.conf中listen_addresses和pg_hba.conf认证规则）
留意 boolean 值在 Permissive 下仍影响部分行为
虽然 Permissive 不执行拒绝，但某些 SELinux boolean（如 httpd_can_network_connect）会影响服务的**初始能力声明**，尤其涉及 cap_net_bind_service 或 cap_sys_chroot 等 capability 的继承。不过这类影响极少见，仅在以下情况需怀疑：
- 服务明确报错含
Permission denied且发生在 fork/exec 或 setuid/setcap 操作中（非 socket bind/connect） - 使用
sesearch -b httpd_can_network_connect查看该 boolean 控制哪些规则，再结合ausearch -m avc -ts recent看是否有相关 denied 记录（即使 Permissive 也会记） - 临时开启对应 boolean 测试：
setsebool -P httpd_can_network_connect on，再重启服务
不复杂但容易忽略：Permissive 是 SELinux 的“只记录不拦截”，它从不干预系统调用成败。服务被拒，请先放下 SELinux，盯住防火墙、服务状态、端口绑定和配置权限这四点。
