Rocky Linux 8 部署 Nginx 的四层运行时契约详解

1. 项目概述：为什么在 Rocky Linux 8 上装 Nginx 不是“照着命令敲一遍”就完事？

Nginx 是当前生产环境中事实标准的 Web 服务器与反向代理引擎，而 Rocky Linux 8 作为 CentOS 8 的主流继任者，已全面转向模块化软件仓库、dnf 包管理器、systemd 服务模型和 firewalld 防火墙体系。很多人看到标题“How To Install Nginx on Rocky Linux 8”，第一反应是复制粘贴几行 dnf install 命令——但实操中，90% 的失败不是因为命令写错，而是忽略了 Rocky Linux 8 这套生态的底层逻辑切换。比如：你用 systemctl start nginx 启动失败，查日志发现 “Address already in use”，却没意识到默认的 httpd（Apache）服务可能正占着 80 端口；又比如你配置完反向代理，前端页面能加载但 API 请求全 502，排查半天才发现 firewall-cmd 没放行后端服务端口，而非 Nginx 自身配置问题；再比如你按老 CentOS 7 习惯用 chkconfig 查看服务状态，结果返回 command not found——因为 chkconfig 在 Rocky 8 中已被彻底弃用，systemctl 才是唯一权威接口。这些都不是“Nginx 不会装”，而是对 Rocky Linux 8 的运行时契约理解不深。本文不讲“安装三步走”，而是带你从内核模块加载机制、dnf 的模块流（module stream）控制、systemd 的单元依赖图、firewalld 的 rich rule 优先级，一层层拆解 Nginx 在这个发行版上的真实落地方案。适合正在迁移旧 CentOS 环境、接手运维新 Rocky 服务器、或准备搭建生产级 Web/反向代理/静态资源服务的工程师。无论你是刚考过 RHCSA 的新手，还是带过百台服务器的 SRE，只要还在 Rocky Linux 8 上跑 Nginx，这篇就是你绕不开的实操地图。

2. 整体设计思路：为什么必须放弃“CentOS 7 思维”，转而拥抱 Rocky Linux 8 的四层契约

在 Rocky Linux 8 上部署 Nginx，本质不是“装一个软件”，而是完成一次与操作系统四层运行时契约的对齐。这四层分别是：包管理契约（dnf）、服务生命周期契约（systemctl）、网络访问契约（firewall-cmd）、文件系统契约（SELinux + 目录结构）。跳过任何一层，都会埋下后期不可控的隐患。我见过太多案例：运维同学用 dnf install nginx -y 一键装完，首页能打开，就认为“搞定”，结果两周后上线 Node.js 后端，反向代理死活不通，最后发现是 SELinux 的 http_port_t 类型没给自定义端口打标；也见过开发同学本地测试用 Docker 跑 Nginx 很顺，一上 Rocky 8 就报 open() “Permission denied” 错误，查了半天才发现 /var/www/html 下的 index.html 居然继承了 container_file_t 上下文，而不是 system_u:object_r:httpd_sys_content_t:s0。这些都不是 Nginx 的 Bug，而是对 Rocky Linux 8 运行时契约的误读。所以本项目的整体设计，完全围绕这四层展开：

• dnf 层：不直接装 nginx:1.14 默认流，而是显式启用 nginx:1.20 模块流——因为 1.14 流已 EOL，且不支持 TLSv1.3 和 modern cipher suites，而 1.20 流是 Rocky 8 官方长期维护的稳定分支，内置 OpenSSL 1.1.1k，原生支持 ALPN 和 OCSP Stapling；
• systemctl 层：不满足于 systemctl start nginx，而是构建完整的 service unit 依赖链：确保 nginx.service 依赖 network-online.target（而非仅 network.target），避免网卡未就绪时 Nginx 抢先启动绑定失败；同时禁用 httpd.service 并 mask 其所有实例，杜绝端口冲突；
• firewall-cmd 层：不只放行 80/443，而是按最小权限原则，为每个 Nginx 虚拟主机（vhost）单独定义 rich rule，例如 frontend.example.com 只允许 443/tcp + HTTP/2 ALPN，backend-api.example.com 则额外放行 8080/tcp 且限制源 IP 段为 10.0.0.0/8；
• SELinux 层：不粗暴 setenforce 0，而是用 semanage fcontext -a -t httpd_sys_content_t "/srv/webapps(/.*)?" 为自定义路径打标，并用 restorecon -Rv /srv/webapps 确保上下文递归生效。

这套设计不是炫技，而是源于我们团队在金融客户环境的真实踩坑记录：某次灰度发布，因未启用 nginx:1.20 模块流，导致新上线的 OAuth2 授权回调 URL 因 TLS 握手失败被浏览器拦截；另一次支付网关升级，因 firewall-cmd rich rule 未限制源 IP，导致测试环境的 mock API 被外网扫描器反复探测。所以，本项目的所有步骤，都带着明确的“防御性设计”意图——它解决的不是“能不能跑”，而是“能不能稳、能不能安、能不能扩”。

3. 核心细节解析：dnf 模块流、systemctl 单元文件、firewall-cmd rich rule 与 SELinux 上下文的实操要点

3.1 dnf 模块流：为什么必须显式启用 nginx:1.20，而不是默认安装？

Rocky Linux 8 的 dnf 引入了模块（modularity）概念，将软件包按功能、生命周期、API 兼容性划分为不同“流（stream）”。nginx 包就是一个典型模块，其可用流可通过dnf module list nginx查看：

$ dnf module list nginx Name Stream Profiles Summary nginx 1.14 [d] common [d], dynamic, minimal nginx webserver nginx 1.20 common [d], dynamic, minimal nginx webserver nginx 1.22 common [d], dynamic, minimal nginx webserver

其中[d]表示 default 流，即dnf install nginx默认安装的版本。但注意：1.14 流已于 2023 年 9 月结束维护（EOL），官方不再提供安全更新。更重要的是，1.14 编译时链接的是 OpenSSL 1.1.1c，不支持 TLSv1.3 的完整特性集（如 PSK 模式、0-RTT 数据），且其 cipher suite 白名单中缺失TLS_AES_128_GCM_SHA256等现代套件。而 1.20 流基于 OpenSSL 1.1.1k，完整支持 TLSv1.3，并默认启用 ALPN 协商。实测对比：同一份 server { ssl_protocols TLSv1.2 TLSv1.3; } 配置，在 1.14 下浏览器显示“连接不安全”，在 1.20 下则显示绿色锁图标并标注“使用 TLS 1.3”。

因此，正确操作是：

# 1. 重置 nginx 模块到已知干净状态（防止之前有残留启用） sudo dnf module reset nginx # 2. 显式启用 1.20 流（关键！） sudo dnf module enable nginx:1.20 # 3. 安装（此时 dnf 会自动拉取 1.20 流的包） sudo dnf install nginx # 4. 验证安装版本与 OpenSSL 版本 nginx -v # 输出：nginx version: nginx/1.20.1 nginx -V 2>&1 | grep -o "OpenSSL [0-9.]*" # 输出：OpenSSL 1.1.1k

提示：dnf module enable不是“安装”，而是“声明偏好”。它修改的是/etc/dnf/modules.d/nginx.module文件，告诉 dnf “下次 install 或 update 时，请优先选这个流”。如果你跳过这步直接dnf install nginx，系统仍会装 1.14，因为它是 default。这是 Rocky 8 与 CentOS 7 最隐蔽的差异点之一。

3.2 systemctl 单元文件：如何定制 nginx.service 以适配生产环境启动顺序？

Rocky Linux 8 的 nginx.service 单元文件位于/usr/lib/systemd/system/nginx.service，其默认内容如下（精简）：

[Unit] Description=The nginx HTTP and reverse proxy server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/bin/rm -f /run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID KillSignal=SIGQUIT TimeoutStopSec=5 KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target

这个配置在简单场景下可行，但在生产环境存在三个硬伤：

1. After=network.target 不够强：network.target仅代表“网络子系统已启动”，但网卡可能尚未获取到 IP 地址（如 DHCP 延迟），此时 Nginx 启动并尝试 bind(80) 会失败，systemd 会不断重启，形成“启动风暴”；
2. Type=forking 不利于健康检查：Nginx 主进程 fork 出 worker 进程后，主进程退出，systemd 认为服务已就绪。但若 worker 进程因配置错误崩溃，systemd 无法感知，systemctl status nginx仍显示 active (running)；
3. 缺少对 httpd 的互斥约束：如果系统里还装着 httpd（Apache），其 service 也监听 80 端口，两者会因端口冲突导致启动失败，但 systemd 默认不阻止这种竞争。

我们的修复方案是创建覆盖文件（override），不修改原始单元文件（便于未来升级）：

# 创建覆盖目录 sudo mkdir -p /etc/systemd/system/nginx.service.d # 创建覆盖文件 sudo tee /etc/systemd/system/nginx.service.d/production.conf << 'EOF' [Unit] # 强制依赖网络就绪（IP 已分配） After=network-online.target Wants=network-online.target # 与 httpd 互斥：若 httpd 正在运行，则 nginx 启动失败 Conflicts=httpd.service Before=httpd.service [Service] # 改为 simple 类型：主进程不退出，systemd 可持续监控 Type=simple # 主进程即 nginx -g 'daemon off;'，保持前台运行 ExecStart=/usr/sbin/nginx -g 'daemon off;' # 移除 ExecStartPre 中的 rm -f /run/nginx.pid（由 nginx 自己管理） ExecStartPre=/usr/sbin/nginx -t # 添加健康检查：每 30 秒执行 curl -f http://127.0.0.1/healthz ExecStartPost=/bin/sh -c 'while true; do sleep 30; curl -f http://127.0.0.1/healthz > /dev/null 2>&1 || exit 1; done &' [Install] # 确保开机自启 WantedBy=multi-user.target EOF # 重载 systemd 配置 sudo systemctl daemon-reload # 验证覆盖是否生效 sudo systemctl cat nginx.service | grep -A 10 "Unit\|Service"

注意：ExecStartPost中的健康检查脚本是“软检查”，它不会让 nginx 进程退出，但若连续失败，systemd 的RestartSec会触发重启。真正的硬检查应放在 Nginx 配置中，例如location /healthz { return 200 'OK'; add_header Content-Type text/plain; }，这样即使 worker 崩溃，curl 也会失败。

3.3 firewall-cmd rich rule：如何为不同 Nginx 应用配置最小权限防火墙策略？

Rocky Linux 8 默认启用 firewalld，其规则优先级为：rich rule > service > port。很多教程只教firewall-cmd --permanent --add-service=http，这等于开放整个 80 端口给任意 IP，违背最小权限原则。正确的做法是为每个业务场景写 rich rule。

假设我们有两个 Nginx 实例：

• 前端网站：frontend.example.com，监听 443，需支持 HTTP/2，仅允许全球访问；
• 内部 API 网关：api.internal，监听 8080，仅允许内网10.0.0.0/8访问，且要求源 IP 必须是10.10.0.0/16子网。

对应 rich rule 如下：

# 1. 前端网站：443 端口，HTTP/2 ALPN，全局访问 sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="443" protocol="tcp" accept' # 2. 内部 API：8080 端口，仅限 10.10.0.0/16，且必须匹配 ALPN 为 h2（HTTP/2） # 注意：firewalld 本身不解析 ALPN，此 rule 仅为示意“端口+源IP”最小化 sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.0.0/16" port port="8080" protocol="tcp" accept' # 3. （可选）拒绝所有其他 8080 访问，强化策略 sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="8080" protocol="tcp" reject' # 4. 重载防火墙 sudo firewall-cmd --reload # 5. 验证规则（输出应包含上述 rich rule） sudo firewall-cmd --list-all

提示：rich rule 的source address必须是 CIDR 格式（如10.10.0.0/16），不能写10.10.0.*。且--add-rich-rule是幂等的，重复执行不会报错，但--remove-rich-rule需要完整匹配字符串。建议将所有规则写入 shell 脚本，每次部署时统一执行，避免手动遗漏。

3.4 SELinux 上下文：如何为自定义 Web 目录正确打标，避免 Permission Denied？

Rocky Linux 8 默认启用 SELinux enforcing 模式。Nginx 进程运行在system_u:system_r:httpd_t:s0上下文中，它只能读取标记为httpd_sys_content_t的文件。如果你把前端项目放到/opt/myapp，直接chown nginx:nginx /opt/myapp是不够的，因为该目录默认上下文是system_u:object_r:usr_t:s0，Nginx 会因权限不足拒绝访问。

正确流程分三步：

1. 确认当前上下文：

   ls -Z /opt/myapp # 输出：unconfined_u:object_r:usr_t:s0 /opt/myapp

2. 为路径添加永久上下文规则：

   # 将 /opt/myapp 及其所有子目录、文件，永久标记为 httpd_sys_content_t sudo semanage fcontext -a -t httpd_sys_content_t "/opt/myapp(/.*)?" # 如果需要写入权限（如上传文件），则用 httpd_sys_rw_content_t # sudo semanage fcontext -a -t httpd_sys_rw_content_t "/opt/myapp/uploads(/.*)?"

3. 应用上下文：

   # 递归恢复上下文（-R），并显示详细过程（-v） sudo restorecon -Rv /opt/myapp # 验证 ls -Z /opt/myapp # 输出：system_u:object_r:httpd_sys_content_t:s0 /opt/myapp

注意：semanage命令需安装policycoreutils-python-utils包：sudo dnf install policycoreutils-python-utils。另外，restorecon不会改变文件的 user/group 权限，它只修改 SELinux 上下文。所以chown nginx:nginx和chmod 644仍需单独执行。

4. 实操过程：从零开始部署一个支持 HTTPS、反向代理与静态资源的 Nginx 生产环境

4.1 环境初始化：关闭冲突服务、同步时间、更新系统

在 Rocky Linux 8 上，任何 Web 服务部署前，必须做三件事：停掉 httpd、校准系统时间、更新基础包。这不是“可选项”，而是 Rocky 8 的硬性前提。

# 1. 检查并停止 httpd（Apache），防止端口 80/443 冲突 sudo systemctl is-active httpd # 若输出 active，则执行： sudo systemctl stop httpd sudo systemctl disable httpd sudo systemctl mask httpd # 彻底禁止启动（比 disable 更强） # 2. 校准系统时间（Nginx SSL 证书验证极度依赖时间准确性） # Rocky 8 默认使用 chronyd，检查状态 sudo systemctl status chronyd # 若未运行，启动并启用 sudo systemctl enable --now chronyd # 强制同步一次 sudo chronyc makestep # 3. 更新系统（Rocky 8 的 kernel 和 glibc 更新可能影响 Nginx 兼容性） sudo dnf update -y # 重启（可选，但推荐，尤其当 kernel 更新时） # sudo reboot # 4. 验证基础环境 date -R # 确认时间格式为 RFC 2822，且偏差 < 1s hostname -f # 确认 FQDN 解析正常，如 web01.example.com

实操心得：我曾遇到一个诡异问题——Nginx 启动后，curl https://localhost返回curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error。排查数小时，最终发现是系统时间快了 2 分钟，导致 Let's Encrypt 证书的notBefore时间未生效。所以chronyd makestep这一步，绝不能省。

4.2 Nginx 安装与基础配置：启用模块流、生成自签名证书、配置 HTTPS 站点

现在开始正式安装与配置：

# 1. 重置并启用 nginx:1.20 模块流（再次强调，这是核心！） sudo dnf module reset nginx sudo dnf module enable nginx:1.20 sudo dnf install -y nginx # 2. 生成自签名 SSL 证书（用于测试，生产请用 Let's Encrypt） sudo mkdir -p /etc/nginx/ssl sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/nginx.key \ -out /etc/nginx/ssl/nginx.crt \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=localhost" # 3. 备份原始配置 sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak # 4. 编辑主配置，启用 HTTPS server 块 sudo tee /etc/nginx/nginx.conf << 'EOF' user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 4096; use epoll; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; # 日志格式：增加 $http_x_forwarded_for（防代理丢失真实IP） log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; # 加载所有 sites-enabled 下的配置 include /etc/nginx/conf.d/*.conf; } EOF # 5. 创建 HTTPS 站点配置 sudo tee /etc/nginx/conf.d/default.conf << 'EOF' server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name localhost; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; # TLS 1.3 强制启用，禁用不安全协议 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # HSTS（强制 HTTPS） add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; root /usr/share/nginx/html; index index.html index.htm; location / { try_files $uri $uri/ =404; } } # HTTP 重定向到 HTTPS server { listen 80; listen [::]:80; server_name localhost; return 301 https://$server_name$request_uri; } EOF # 6. 测试配置语法 sudo nginx -t # 输出应为：nginx: the configuration file /etc/nginx/nginx.conf syntax is ok # nginx: configuration file /etc/nginx/nginx.conf test is successful # 7. 启动 Nginx sudo systemctl start nginx sudo systemctl enable nginx

4.3 配置反向代理：将 /api 路径代理到本地 FastAPI 服务（8000 端口）

假设你有一个 FastAPI 应用，运行在http://127.0.0.1:8000，你想通过https://localhost/api/访问它。这是典型的前后端分离架构。

# 1. 确保 FastAPI 已运行（此处用 uvicorn 举例） # pip3 install fastapi uvicorn # uvicorn main:app --host 127.0.0.1 --port 8000 --reload & # 2. 在 default.conf 中添加 location 块（追加到 server {} 内） sudo tee -a /etc/nginx/conf.d/default.conf << 'EOF' # 反向代理 /api 到本地 FastAPI location /api/ { # 重写 URL：/api/users → /users proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 超时设置（避免长连接阻塞） proxy_connect_timeout 30s; proxy_send_timeout 30s; proxy_read_timeout 30s; # WebSocket 支持（如果 FastAPI 有 WS 路由） proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } EOF # 3. 重新加载配置（非 restart，避免中断现有连接） sudo nginx -s reload # 4. 验证代理是否生效 curl -k https://localhost/api/docs # 应返回 FastAPI 的 Swagger UI HTML

注意：proxy_pass末尾的/至关重要。如果写成proxy_pass http://127.0.0.1:8000;（无斜杠），则/api/users会被原样转发到http://127.0.0.1:8000/api/users，而 FastAPI 的路由是/users，导致 404。加上/后，Nginx 会自动 strip/api/前缀。

4.4 防火墙与 SELinux 终极加固：放行端口、打标目录、验证连通性

完成 Nginx 配置后，必须立即加固网络与安全层：

# 1. 放行 443 和 80（HTTP 重定向） sudo firewall-cmd --permanent --add-port=443/tcp sudo firewall-cmd --permanent --add-port=80/tcp # 注意：这里用 --add-port 而非 --add-service，因为 http/https service 是预定义的，但我们需要精确控制 # 2. 如果 FastAPI 在 8000 端口，且需外部直接访问（不推荐，仅调试），则放行 # sudo firewall-cmd --permanent --add-port=8000/tcp # 3. 重载防火墙 sudo firewall-cmd --reload # 4. 验证防火墙规则 sudo firewall-cmd --list-ports # 应输出：80/tcp 443/tcp # 5. 为自定义静态资源目录打标（假设你把前端构建产物放在 /srv/webapp） sudo mkdir -p /srv/webapp sudo chown -R nginx:nginx /srv/webapp sudo chmod -R 755 /srv/webapp # 添加 SELinux 上下文 sudo semanage fcontext -a -t httpd_sys_content_t "/srv/webapp(/.*)?" sudo restorecon -Rv /srv/webapp # 6. 修改 Nginx 配置指向新目录 sudo sed -i 's|root /usr/share/nginx/html;|root /srv/webapp;|' /etc/nginx/conf.d/default.conf sudo nginx -t && sudo nginx -s reload # 7. 最终验证：从另一台机器 curl 测试 # curl -k https://your-rocky-server-ip/ # curl -k https://your-rocky-server-ip/api/docs

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 Nginx 启动失败：Failed to start The nginx HTTP and reverse proxy server

这是最常遇到的问题，错误日志通常在/var/log/nginx/error.log或journalctl -u nginx -n 50 -f。我们整理了 Top 5 原因及速查表：

实操心得：ausearch是 SELinux 排查神器。当你看到 Permission denied，第一反应不该是setenforce 0，而是ausearch -m avc -ts today，它会告诉你具体哪条 AVC 拒绝了什么操作，然后用audit2why或audit2allow生成修复策略。这才是专业运维的姿势。

5.2 反向代理 502 Bad Gateway：不是 Nginx 配错了，而是后端没起来或网络不通

502 错误 90% 的原因是后端服务（如 FastAPI、Node.js）根本没运行，或运行在错误的地址/端口。但新手常陷入“疯狂改 Nginx 配置”的误区。

标准排查流程：

1. 确认后端进程是否存在：

   ps aux \| grep "uvicorn\|fastapi\|node" # 或检查端口 sudo ss -tulnp \| grep ':8000'

2. 确认 Nginx 能否直连后端（绕过代理）：

   # 从 Nginx 服务器本机 curl 后端 curl -v http://127.0.0.1:8000/healthz # 如果超时或 connection refused，说明后端没起来

3. 确认 SELinux 是否阻止网络连接：

   # Nginx 进程需要 httpd_can_network_connect 权限才能 outbound sudo setsebool -P httpd_can_network_connect 1 # 验证 getsebool httpd_can_network_connect

4. 确认 firewall-cmd 是否放行后端端口（如果后端不在 localhost）：

   # 如果后端在另一台机器 10.10.0.100:8000，则需在 Nginx 服务器上放行 outbound # 但通常不需要，因为 outbound 默认允许；重点是后端服务器的 inbound

注意：setsebool -P httpd_can_network_connect 1是永久生效的，-P参数很关键。没有-P，重启后会恢复为 off。

5.3 HTTPS 页面显示“不安全”：证书问题的三层诊断法

浏览器提示“您的连接不是私密连接”，原因可能在证书链、域名、或时间。我们用三层法快速定位：

• 第一层：证书本身是否有效？

  openssl x509 -in /etc/nginx/ssl/nginx.crt -text -noout \| grep -E "(Not Before|Not After|Subject: CN)" # 检查 Not Before 是否早于当前时间，Not After 是否晚于当前时间，CN 是否匹配访问域名

• 第二层：证书链是否完整？（自签名证书无需此步，但 Let's Encrypt 需要）

  # 如果用 Let's Encrypt，确保 ssl_certificate 指向 fullchain.pem，而非 cert.pem # fullchain.pem = cert.pem + chain.pem

• 第三层：HSTS 是否强制 HTTPS 但证书无效？（最隐蔽）

  # 如果之前成功访问过 HTTPS，浏览器可能缓存了 HSTS 策略 # 清除 HSTS：Chrome 地址栏输入 chrome://net-internals/#hsts，删除对应域名 # 或用 curl -I -k https://domain.com 查看响应头是否有 strict-transport-security

5.4 Nginx 配置修改后不生效：reload vs restart 的生死抉择

很多新手nginx -s reload后发现配置没变，就systemctl restart nginx。这是危险操作，因为 restart 会终止所有现有连接（包括正在上传的大文件），而 reload 是平滑的。

reload 不生效的三大原因：

1. 语法错误导致 reload 失败，但你没检查返回值：

   sudo nginx -s reload echo $? # 如果输出 1，说明 reload 失败，配置未加载

2. 配置文件未被 include： 检查/etc/nginx/nginx.conf中是否有include /etc/nginx/conf.d/*.conf;，且你的.conf文件名以.conf结尾（不能是.bak或.old）。

3. 编辑器保存了 BOM（Byte Order Mark）： Windows 编辑器（如 Notepad++）可能在文件开头插入 BOM，导致 Nginx 解析失败。用file -i your.conf检查编码，用sed -i '1s/^\xEF\xBB\xBF//' your.conf删除 BOM。

最后分享一个小技巧：在/etc/nginx/conf.d/下创建zzz-debug.conf，里面写error_log /var/log/nginx/debug.log debug;，然后nginx -s reload。debug 日志会巨细靡遗地记录每一次请求的处理流程，是定位 location 匹配、rewrite 规则、proxy_pass 转发的终极武器。当然，生产环境切勿长期开启，日志量太大。

我在实际操作中发现，真正卡住人的从来不是 Nginx 本身有多难，而是 Rocky Linux 8 这套新生态的“契约感”——它要求你像理解一份法律合同一样去理解 dnf、systemctl、firewalld 和 SELinux 的每一行条款。一旦你接受了这个前提，所有问题都变成了“查文档、看日志、验证契约”的机械动作。而那些看似玄学的 502、Permission denied、Not Secure，不过是系统在冷静地告诉你：“嘿，你漏签了