worker_connections本身不触发selinux拦截，但高并发下会放大selinux权限不足问题：证书读取、日志写入、上游连接、缓存访问等操作若无对应selinux策略授权，会导致静默拒绝、403/502错误或握手失败；需通过ausearch查avc拒绝、restorecon修复上下文、setsebool启用必要布尔值来解决。
worker_connections 本身不触发 SELinux 拦截，但它间接放大了 SELinux 权限不足时的问题表现。当连接数上升、Nginx 尝试打开更多文件（日志、证书、临时 socket、缓存文件等）或访问更多路径时，SELinux 若未授权对应操作，就会在连接建立的某个环节静默拒绝——不是返回 503，而是直接中断 handshake 或报 403/502，排查起来非常隐蔽。
SELinux 如何在连接链路上“卡住” worker_connections
每个连接背后都涉及多个文件和路径操作，而 SELinux 策略控制着这些动作是否被允许：
- 证书与密钥读取：HTTPS 场景下，worker 进程需读取 .pem 文件；若证书放在非标准路径（如 /opt/certs/），默认策略通常不允许 nginx_t 域访问，会导致 SSL 握手失败，连接被重置
- 日志写入：高并发时 error.log / access.log 写频次升高，若日志目录 SELinux 上下文不是 var_log_t，且策略未放行 write，Nginx 可能降级为只写部分日志，甚至影响 accept 流程
- 代理目标地址解析与连接：反向代理中，worker 进程发起 outbound 连接；若启用了 selinux-policy-targeted 的 strict 策略，nginx_t 默认禁止 network_connect，需手动添加 allow nginx_t self:tcp_socket { connectto }; 或启用布尔值 setsebool -P httpd_can_network_connect 1
- 共享内存与缓存文件访问：使用 proxy_cache 或 limit_req zone 时，Nginx 创建 shm 区或 cache 文件；若 /var/cache/nginx 不是 nginx_cache_t 上下文，worker 启动或运行中可能无法初始化资源，导致连接排队失败
验证是否 SELinux 导致连接异常
不要靠猜，用审计日志定位真实拦截点：
- 执行 ausearch -m avc -ts recent | grep nginx，查看最近是否有 AVC denied 记录
- 临时切到 Permissive 模式：setenforce 0，观察连接是否立即恢复；若恢复，基本确认是 SELinux 限制
- 用 namei -om /path/to/cert.pem 检查证书路径每一层的上下文和权限，尤其注意中间父目录是否为 unconfined_u:object_r:default_t:s0
- 检查当前策略模块：semodule -l | grep nginx，确认是否加载了 nginx 相关自定义策略（如有的话，需同步更新）
安全加固下的兼容配置建议
保持 Enforcing 模式不降级，同时让 worker_connections 发挥作用：
- 将证书、密钥、缓存目录、日志路径统一打上正确上下文，例如：
semanage fcontext -a -t nginx_cert_t "/opt/certs(/.*)?"
restorecon -Rv /opt/certs - 启用必要布尔值：setsebool -P httpd_can_network_connect 1 httpd_read_user_content 1
- 如使用 OCSP stapling，确保 nginx_t 被允许访问网络并读取远程响应，必要时自定义策略模块（用 audit2allow 从 AVC 日志生成）
- 避免关闭 SELinux 或设为 Disabled；Permissive 仅用于诊断，不可长期运行
worker_connections 设得再高，也得过得了 SELinux 这道门。它不拦连接数本身，但会拦连接背后每一次文件访问、每次网络调用、每个上下文切换所需的资源准备。配对调优，才真正稳。
