说实话做了这么多年运维和站点部署我见过太多把 Nginx 当成“纯转发工具”用的案例配置文件里只有几行 proxy_pass证书一挂就当完事大吉HTTP 和 HTTPS 混着跑也毫不在意。等哪天被扫描器薅了羊毛、被刷了流量或者用户浏览器地址栏弹出红字警告才想起来回头补课。Nginx 是当今 Web 世界里最主流的反向代理服务器和 Web 服务器不管是跑静态站、做负载均衡还是给后端服务当网关它几乎都是第一选择。但“装上能用”和“扛得住、守得住、跑得稳”之间隔着一条巨大的鸿沟。这篇实战笔记就围绕 Nginx 安全防护和 HTTPS 部署这条主线把我这些年踩过的坑、调过的参、加过的头系统性地梳理一遍。无论你是刚入门的小白还是已经跑过几个项目的中级开发者只要你手里有一台 Linux 服务器想把自己的站点安全地暴露在公网这篇文章都能给你一套可以直接抄作业的方案。我会从环境准备、基础安全配置、HTTPS 证书部署到反向代理安全、性能调优、常见报错排查一步步展开。全程以实操为主不空谈理论所有配置片段你都可以直接拿去改改用。1. 环境准备与 Nginx 安装部署1.1 选定系统与安装方式Nginx 对 Linux 发行版几乎通吃CentOS、Ubuntu、Debian 都能跑得很稳。我个人的建议是生产环境优先选 Ubuntu 20.04 LTS 以上或 Debian 11 以上apt 源里的 Nginx 版本比较新安全更新跟得也快。CentOS 7 虽然还能用但默认源里的 Nginx 版本太老想用新特性得额外编译徒增工作量。安装方式无外乎三种直接用系统包管理器安装apt install nginx或yum install nginx从 Nginx 官方源安装能拿到最新稳定版源码编译安装适合需要自定义模块的场景我推荐第二种。官方源会同步最新稳定版和安全补丁比系统自带源更及时又不用像源码编译那样折腾依赖。以 Ubuntu 为例先添加官方源sudo apt update sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg echo deb [signed-by/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx装完以后先看一眼版本和编译参数确认关键模块是否已启用nginx -V输出里要重点留意--with-http_ssl_module如果没有它后面配置 HTTPS 就是空谈。官方源的预编译包默认都带这个模块但如果你在网上下载了一些来路不明的“精简版”或“绿色版”就很可能在这儿翻车。1.2 目录结构与最小配置文件解读很多初学者一打开 Nginx 的配置目录就懵了一堆文件夹和文件不知道从哪儿下手。我先画个最简地图/etc/nginx/nginx.conf主配置文件控制全局行为和 http 块/etc/nginx/conf.d/存放额外配置文件主配置里用include引入/var/log/nginx/访问日志和错误日志所在目录/usr/share/nginx/html/默认站点根目录最小可用的站点配置长这样我习惯把它放到/etc/nginx/conf.d/default.confserver { listen 80; server_name example.com www.example.com; root /var/www/example; index index.html; access_log /var/log/nginx/example_access.log; error_log /var/log/nginx/example_error.log; }这段配置只做了一件事监听 80 端口当用户访问example.com时把/var/www/example目录下的文件返回给用户。实际生产环境里这个 server 块会被疯狂扩充加上各种安全头、缓存策略、反向代理规则但核心骨架始终是这三板斧监听什么端口、匹配哪个域名、资源放在哪儿。1.3 配置文件语法自检与平滑重载Nginx 的配置文件写错了不会当场报警最常见的翻车场景就是改完配置直接nginx -s reload结果工作进程直接退出站点全部 502。所以每次改完配置必须先做语法检查nginx -t看到syntax is ok和test is successful才算过关。如果报错会直接告诉你哪个文件第几行有问题照着改就行。平滑重载和硬重启有本质区别。nginx -s reload会让 Nginx 重新加载配置同时保持现有连接不中断非常适合生产环境。而service nginx restart或systemctl restart nginx会先停掉所有工作进程再重新启动哪怕只有几毫秒在线用户也会感知到连接抖动。我的习惯是只要不是改监听端口这种底层变更一律用 reload。提示改配置之前先备份一份。cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak这行命令能让你在配置改崩之后三秒内回到安全状态。2. NGINX 核心配置与基础安全加固2.1 隐藏版本号与关闭无用模块Nginx 默认会在 HTTP 响应头里暴露版本号形如Server: nginx/1.24.0。攻击者拿到这个信息就能针对已知漏洞快速匹配攻击方案。虽然老话说“安全不能靠隐藏”但减少信息暴露永远是值得做的第一步。隐藏版本号只需在主配置文件的http块里加一行server_tokens off;这一项做完响应头会变成Server: nginx只保留软件名不带具体版本。更激进的做法是彻底修改响应头里的Server字段用自定义字符串顶替。需要安装headers-more-nginx-module模块然后配置more_set_headers Server: MyWebServer;但这种做法有副作用一是模块需要额外编译二是如果后续排查问题要抓包分析看到陌生的 Server 头容易误判。我平时只做server_tokens off在隐藏和可维护性之间取平衡。2.2 禁用不安全的 HTTP 方法默认配置下Nginx 会响应TRACE、DELETE、PUT等非必要的 HTTP 方法。TRACE方法存在跨站追踪风险PUT和DELETE如果被利用可能直接对静态资源做修改。很多安全扫描工具拿到这类响应就会把站点标记为“风险项”。在 server 块里加一段限制if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; }这样除了正常的 GET、HEAD、POST其他方法直接返回 405。要注意的是如果你的站点有 API 接口用到PUT或PATCH就得把对应方法加进白名单别一刀切把自己业务的合法请求也拦了。2.3 关键安全响应头配置安全那头是 HTTP 协议层面抵御攻击最有效的手段之一。所谓“安全头”就是服务端在响应时附带的一组特殊 HTTP 头告诉浏览器应该对当前页面采取什么安全策略。Nginx 里配置它们非常方便在server或location块中加入add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; add_header X-XSS-Protection 1; modeblock always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Content-Security-Policy default-src self; script-src self unsafe-inline; style-src self unsafe-inline; img-src self data: always;逐个解释一下X-Content-Type-Options: nosniff禁止浏览器对响应内容做 MIME 类型猜测防止某些文件被渲染成可执行脚本X-Frame-Options: SAMEORIGIN禁止页面被嵌入到其他网站的 iframe 中这是防御点击劫持的核心手段X-XSS-Protection启用浏览器内置的 XSS 过滤机制虽然现代浏览器对这个头的依赖度在下降但加上总没坏处Referrer-Policy控制页面跳转时携带多少来源信息防止路径中的敏感参数意外泄露给第三方Content-Security-Policy内容安全策略白名单机制告诉浏览器页面可以加载哪些来源的资源这里有个最常见的坑add_header指令如果在location块内使用Nginx 会丢弃在server块里定义的同名响应头不向下合并。所以如果你在某个 location 里引用了 add_header就必须把该加的头都加全否则就会出现“为什么这个接口有安全头、那个接口没有”的诡异现象。2.4 访问控制与请求频率限制访问控制的核心逻辑就一句话谁可以访问谁必须滚。最常见的做法是基于 IP 的访问控制location /admin { allow 192.168.1.0/24; deny all; }这段配置只允许内网网段访问/admin路径其他来源一律拒绝。对管理后台类路径来说这套规则简单粗暴且极其有效。与之搭配的是limit_req模块用于限制单 IP 的请求频率防刷防爆破的效果立竿见影。在http块定义限流区域limit_req_zone $binary_remote_addr zoneapi_limit:10m rate10r/s;然后在需要保护的location中应用location /api/ { limit_req zoneapi_limit burst20 nodelay; }这里的rate10r/s表示每秒放行 10 个请求burst20表示允许最多 20 个请求排队等待nodelay表示排队的请求直接处理而不是延迟。实际数字要根据业务量调整API 接口写死 10r/s 可能直接误伤正常用户。我见过有人把登录接口限到了 1r/s结果用户疯狂输错密码时直接触发封禁体验稀烂。登录接口限到 5r/s普通接口限到 20r/s算是比较稳妥的起步配置。3. HTTPS 部署实战从证书申请到强制跳转3.1 证书类型选择与获取HTTPS 的本质是 TLS 加密传输而证书是 TLS 握手的信任基石。根据验证级别证书主要分三类域名验证型DV验证你拥有该域名申请最快个人站点和中小项目的首选组织验证型OV验证企业主体信息适合公司官网、电商平台扩展验证型EV验证最严格浏览器地址栏会显示绿色单位名称一般大企业才会用对绝大多数场景来说DV 证书完全够用。Lets Encrypt 提供免费 DV 证书90 天有效期支持自动续期是目前应用最广的方案。如果对证书有效期有焦虑也可以用 ZeroSSL同样是免费 DV 证书支持 90 天有效期。申请证书最省心的方式是用 Certbot 工具一条命令搞定申请和配置。以 Ubuntu Nginx 为例sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d example.com -d www.example.comCertbot 会自动检测 Nginx 配置完成域名验证后把证书下载到本地并自动改写 Nginx 配置文件加上 443 监听和证书路径。整个流程是交互式的跟着提示走就行基本不会出岔子。3.2 证书与私钥配置详解如果你的证书不是通过 Certbot 自动配置的比如从云厂商或第三方机构申请的付费证书就需要手动把证书文件上传到服务器并配置。我习惯把证书文件统一放在/etc/nginx/ssl/目录下按域名建子目录方便管理mkdir -p /etc/nginx/ssl/example.com # 上传证书和私钥到该目录然后配置 HTTPS server 块server { listen 443 ssl; http2 on; server_name example.com www.example.com; ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem; 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 on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_session_tickets off; ... }这里要重点强调的是ssl_protocols。TLSv1.0和TLSv1.1属于老古董协议存在多个已知安全漏洞2020 年后主流浏览器均已停止支持直接禁用。TLSv1.2和TLSv1.3是当前的安全基线其中TLSv1.3握手更快、加密套件更强建议只要客户端兼容性允许就优先启用。ssl_ciphers那一长串看着让人头皮发麻实际上是从 Mozilla 推荐的现代加密套件列表里摘出来的按优先级排序优先使用 ECDHE 密钥交换和 GCM 分组模式。如果你的站点用户都是现代浏览器可以直接简化成ssl_ciphers HIGH:!aNULL:!MD5:!3DES;3.3 HTTP 自动跳转 HTTPS部署好 HTTPS 之后如果不强制跳转用户访问http://example.com时仍然会走明文传输。访问量少的时候不觉得有啥真等有人在你网站上提交了表单、输入了密码数据就是裸奔状态。而且搜索引擎优化也不喜欢一个站点同时存在 HTTP 和 HTTPS 两套地址。最经典的做法是单独开一个 80 端口的 server 块专门做跳转server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }这里用301而不是302原因是 301 是永久重定向浏览器和搜索引擎会直接缓存结果后续再访问旧地址就直接走 HTTPS 了省去一跳。而 302 是临时跳转每次都要重新请求原地址再跳多一次网络往返损耗。注意配置 301 跳转后务必先确认 HTTPS 站点能正常访问再切流量。我见过有人先全站 HTTP 跳 HTTPS 然后才发现证书没挂对整个站点陷入“跳转失败”的死循环用户全部访问不了。3.4 证书自动续期与替换Lets Encrypt 证书只有 90 天有效期手动续期是件极其反人类的事。一个月黑风高的深夜证书静悄悄过期第二天早晨用户打开浏览器看到红色警告——这种事故我经历过不止一次。Certbot 提供了自动续期机制。配置完成后可以先用 dry-run 模式测试一下certbot renew --dry-run看到Congratulations字样的输出说明续期流程能正常走通。然后让 cron 定期执行续期命令echo 0 3 * * * /usr/bin/certbot renew --quiet --renew-hook systemctl reload nginx | sudo tee /etc/cron.d/certbot-renew这里加renew-hook的意义在于证书文件本身被替换后Nginx 需要重新加载配置才能读取到新证书。如果不加这个 hook续期虽然成功但 Nginx 可能还在用旧证书同样会过期报废。如果你申请的证书不是 Lets Encrypt而是云厂商的付费证书那就得走手动替换流程。替换的操作步骤其实就三步上传新证书文件到服务器、修改 Nginx 配置里的证书路径、nginx -s reload。但这里有个高频翻车点很多人在传完证书后只重启 Nginx不检查证书文件权限导致 Nginx 工作进程没有读取权限直接启动失败。chmod 600 /etc/nginx/ssl/example.com/privkey.pem chmod 644 /etc/nginx/ssl/example.com/fullchain.pem私钥权限必须收紧到 600证书链可以放宽到 644 让所有人都能读反正证书本身是公开信息。4. 反向代理场景下的安全与性能调优4.1 基本反向代理配置与转发头设置Nginx 作为反向代理时核心配置是proxy_pass把这行写进 location 块请求就会被转发到指定的后端地址。但直接裸配 proxy_pass 会带来一系列问题最典型的就是后端程序拿不到用户的真实 IP。举个例子你的 Nginx 代理到后端的 Tomcat 或 Node.js 服务后端在做访问日志、风控、限流时都得依赖客户端 IP。而 Nginx 转发请求时默认只带自己的内网地址后端看到的“客户端 IP”永远是 127.0.0.1。解决这个问题得靠一组转发头location /api/ { proxy_pass http://backend_server; 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_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; }这段配置里的$host是客户端请求的原始域名$remote_addr是客户端真实 IP$proxy_add_x_forwarded_for会在原有的 X-Forwarded-For 基础上追加上当前客户端 IP。X-Forwarded-Proto用于标明原始请求是 HTTP 还是 HTTPS很多后端框架靠这个头来生成正确的站内链接和重定向地址。如果你后端配置了 HTTPS 且启用了 HSTS这一组头尤其重要。否则可能出现“后端生成的重定向链接全是 http”的诡异问题排查半天发现是转发头缺了X-Forwarded-Proto。4.2 WebSocket 与 SSE 长连接代理现代 Web 应用大量使用 WebSocket 做实时通信Nginx 代理 WebSocket 倒是很简单只需在配置里加两个升级头location /ws/ { proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }proxy_http_version 1.1很重要因为 HTTP/1.0 不支持 Upgrade 机制。Upgrade和Connection这两个头的作用是告诉后端这个连接请你升级为 WebSocket 协议。少了任何一个WebSocket 握手就会失败前端报WebSocket is closed before the connection is established。SSEServer-Sent Events是另一种常见的实时推送方案比 WebSocket 轻量但它的代理配置有一个隐蔽的坑Nginx 默认会缓冲后端响应而 SSE 依赖实时的持续数据流如果缓冲开启数据会攒够了才一次性推送前端看到的就不是实时数据了。解决方法是显式关掉缓冲location /sse/ { proxy_pass http://backend_sse; proxy_buffering off; proxy_cache off; add_header X-Accel-Buffering no; }4.3 代理超时参数精细调节反向代理场景下超时参数是用来保命的。默认的proxy_read_timeout是 60 秒如果后端处理一个请求超过 60 秒还没返回Nginx 会直接断开连接返回 504。对大文件导出、批量任务这种耗时操作来说这个时间远远不够。我常用的超时配置组合proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 120s;三个参数分别控制连接后端服务器的超时、向后端发送请求数据的超时、等待后端响应数据的超时。proxy_connect_timeout默认 60 秒其实太长了。后端在内网连接建立失败的场景基本都是端口没监听、服务挂了、网络不通正常情况下 1 秒内就能连上。设成 5 秒能让故障被快速感知避免用户长时间白屏等待。4.4 反向代理场景的敏感路径防护反向代理最常见的需求就是把内网服务暴露到公网。但内网服务之间往往互相依赖比如前端页面上一个请求可能会调用多个后端接口于是公网入口需要按路径分发到不同服务。这个过程中稍不注意就会把不该暴露的接口透出去。我发生过一次事故Grafana 的配置页面被完整暴露到了公网虽然访问需要密码但让攻击者看到了登录页面和框架版本号。后来凡是做代理都会加一套收口规则。对内网管理类服务用location精确匹配加上访问控制location /admin { return 404; } location /admin/ { allow 127.0.0.1; deny all; }还有一个容易忽视的路径/nginx_status。这是 Nginx 自带的监控信息页会显示当前连接数、请求数等运行状态。如果不做保护就直接暴露到公网等于告诉所有人“这个站点的体积有多大、当前压力有多高”location /nginx_status { stub_status; allow 127.0.0.1; allow 192.168.1.0/24; deny all; }5. HTTPS 安全增强与性能优化5.1 TLS 会话复用与会话票证TLS 握手是整个 HTTPS 请求中耗时最明显的环节。如果每个请求都要走完整的 TLS 握手流程服务端和客户端都要做一次非对称加密计算在移动网络环境下延迟可能直接翻倍。会话复用就是用来解决这个问题的。Nginx 里有两套机制会话缓存和会话票证。ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d;ssl_session_cache shared:SSL:10m的含义是分配 10MB 的共享内存用于保存 TLS 会话信息。在 Nginx 多进程模型下各进程必须使用共享内存才能互相读取会话数据。10MB 大约能存 2 万个会话对一般站点来说足够。会话票证是另一种方案原理是把会话状态加密后用 cookie 存到客户端服务端无状态。配置只需一行ssl_session_tickets on;但这里有两个注意点。一是会话票证的密钥需要定期轮换否则旧密钥泄露会导致所有历史会话可被解密。二是如果你有多台 Nginx 做负载均衡会话票证密钥在各节点间必须一致否则用户被轮询到另一台机器时票证无法验证会话复用直接失效。此时需要额外配置共享密钥ssl_session_ticket_key /etc/nginx/ssl/session_ticket.key;5.2 OCSP 装订配置OCSP在线证书状态协议是用来查询证书是否被吊销的机制。默认情况下浏览器访问一个 HTTPS 站点时会自行向 CA 的 OCSP 服务器发起查询确认证书状态。这个查询是额外的网络请求耗时且可能失败。OCSP Stapling 的机制是Nginx 自己定期去 CA 查询证书状态把查询结果缓存下来然后在 TLS 握手时直接把结果“订”进证书里发给客户端。客户端不再需要额外发请求握手更快而且查询结果由服务端统一管理还能缓存。Nginx 配置ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/example.com/fullchain.pem;配置完成后可以用下面命令验证是否生效openssl s_client -connect example.com:443 -status -tlsextdebug 21 | grep OCSP如果看到响应里有OCSP Response Status: successful说明装订正常。如果显示OCSP response no response sent则说明装订失效。常见原因是ssl_trusted_certificate配置的证书链不完整Nginx 无法完成签名验证。5.3 HSTS 强制浏览器走 HTTPSHSTSHTTP 严格传输安全是一种比 301 跳转更强硬的 HTTPS 强制机制。它通过响应头告诉浏览器在指定时间内你访问这个域名只能走 HTTPS任何明文连接都会在浏览器端直接被拦截根本不会发出去。add_header Strict-Transport-Security max-age31536000; includeSubDomains always;max-age31536000表示有效期一年includeSubDomains表示所有子域名也一并强制 HTTPS。这个头是把双刃剑设置之后浏览器会硬性缓存。如果你的站点某些子域名或接口只支持 HTTP开启 includeSubDomains 后这些资源将完全不可达。所以建议第一次启用时先用短时间比如先设max-age300观察几天确认无误再拉长到一年。5.4 TLS 性能摸底与优化TLS 对性能的影响常常被高估。实际上现代 CPU 对 AES 等对称加密算法都有硬件加速指令非对称加密只在握手阶段出现一次。真正影响 HTTPS 性能的往往是会话复用率不够高或握手往返次数太多。利用curl可以从客户端侧直观看到握手耗时curl -o /dev/null -s -w time_namelookup:%{time_namelookup} time_connect:%{time_connect} time_appconnect:%{time_appconnect} time_total:%{time_total}\n https://example.com重点关注time_appconnect和time_connect的差值这就是 TLS 握手耗时。如果发现这个值大于 200ms优先检查会话复用和 OCSP Stapling 是否生效。还想再进阶的话可以把 HTTP/2 开起来。HTTP/2 的多路复用能力让多个请求可以共享同一条 TCP 连接对 HTTPS 性能的提升立竿见影。Nginx 1.25.1 以上版本已经默认支持 HTTP/3但 HTTP/3 需要 UDP 端口 443 配合在部分云厂商的安全组里还得额外放行 UDP配置链路更长。listen 443 ssl; http2 on;就这么一行HTTPS 站点就能获得多路复用能力。6. 常见故障排查与安全加固实战6.1 证书不生效与浏览器报错排查“明明配置了证书为什么还报错”是我收到最多的问题类型之一。最常见的表现是用户访问站点时浏览器提示“连接不安全”或“证书无效”。先按顺序排查确认监听端口ss -tlnp | grep 443没有输出说明 Nginx 根本没监听 443确认配置文件生效nginx -T | grep ssl_certificate看证书路径是否正确加载检查证书文件有效性openssl x509 -in /etc/nginx/ssl/example.com/fullchain.pem -noout -dates检查证书是否匹配域名证书里的 Common Name 或 Subject Alternative Name 必须包含你访问的域名否则浏览器一定会报“域名不匹配”一个极端常见的原因是“证书链不完整”。有些证书机构只给你签发站点证书不附带中间证书。浏览器拿到站点证书后需要一路追溯到根证书才能验证信任中间断层就报错。解决办法是把站点证书和中间证书拼接成一个 fullchain 文件cat site-cert.pem intermediate-cert.pem fullchain.pem这个文件才是ssl_certificate应该指向的完整证书链。6.2 替换 SSL 证书后不生效的原因“换了新证书reload 了但浏览器还是显示旧证书”——这是另一个高频翻车现场。我排查过几次后发现绝大多数问题出在浏览器缓存上。TLS 会话被客户端缓存了浏览器还没跟服务器重新协商就会继续用旧证书。此时让用户彻底关闭浏览器再重新打开不是刷新页面或者在无痕模式里访问一般就能看到新证书。服务器侧也要确认是否所有进程都加载了新证书。有时nginx -s reload因为配置语法错误等原因没有真正生效但命令本身没报错。最稳妥的验证方式是用curl直接看返回的证书信息curl -v https://example.com 21 | grep subject\|issuer如果显示的证书序列号还是旧的就需要强制重启 Nginxsystemctl restart nginx6.3 前后端跨域与代理 CORS 报错处置跨域报错是 Web 开发里头疼的问题。Nginx 反向代理天然是解决跨域的利器因为浏览器只认域名和端口同一个域名的请求就是同源。把前端静态资源域名的/api路径代理到后端服务域名浏览器视角就完全是同一个站点。但配置 CORS 响应头时容易踩坑OPTIONS预检请求必须正确处理。浏览器在发起跨域请求前会先发送一个OPTIONS请求探测服务器允不允许跨域。如果 Nginx 在location块里没有放行预检请求就会导致跨域失败浏览器报CORS preflight did not succeed。一个稳妥的 CORS 配置location /api/ { add_header Access-Control-Allow-Origin $http_origin always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, DELETE always; add_header Access-Control-Allow-Headers * always; add_header Access-Control-Max-Age 86400; if ($request_method OPTIONS) { return 204; } proxy_pass http://backend_server; }这里Access-Control-Allow-Origin用了$http_origin变量表示动态回显请求方的 Origin。要注意这种方式只适合对安全要求不高的场景因为任何来源都会被允许。生产环境如果只需要给特定域名提供接口应该显式写死set $cors_origin ; if ($http_origin https://example.com) { set $cors_origin https://example.com; } add_header Access-Control-Allow-Origin $cors_origin always;6.4 安全扫描加固实战清单最后把我个人做安全加固的整套流程整理成清单每次部署新站点或者大版本升级时按顺序过一遍更新系统与 Nginx 到最新稳定版配置server_tokens off隐藏版本号禁用不必要的 HTTP 方法配置完整安全响应头X-Frame-Options、CSP、X-Content-Type-Options 等全站部署 HTTPSHTTP 301 跳转HSTS 头配置并确认子域名兼容性TLS 协议只保留 1.2 和 1.3启用 OCSP Stapling 和会话复用管理后台路径做 IP 白名单敏感接口配置limit_req限流访问日志定期切割与清理防止日志文件涨爆磁盘定期用在线工具或 openssl 命令验证证书状态和 TLS 配置按这套清单走完绝大多数基础安全扫描工具都会标记为“安全”或“低风险”。但安全是动态博弈Nginx 的安全防护不是说配置一次就永远躺平需要跟着威胁情报和业务变化持续迭代。7. 我的实操心得做了这么多年的 Nginx 部署和调优我最大的体会是大多数人不是被复杂的功能难倒而是栽在最基础的细节上。证书文件权限没设置对导致 Nginx 起不来add_header 在 location 层覆盖导致安全头失效日志忘切割导致磁盘爆满——这些问题没有一个是高深的技术难题全是基本功不扎实。如果你正在规划一个新的 Nginx 服务我给你的建议是第一次配置时就把安全基线打好别想着“先弄个能跑的以后再补”。因为“以后再补”的结局往往是“再也没补过”。另一个建议是配置要分文件管理不要全部堆在 nginx.conf 里。我会按服务建独立的配置文件放在/etc/nginx/conf.d/下文件名跟域名或服务名对应比如example.com.conf、api-gateway.conf。这样后续排查问题、定位配置都比在几千行的主配置里翻来翻去强得多。最后再分享一个小技巧每次改完配置先跑nginx -t自检再 reload。这个习惯看着不起眼但能帮你避开至少一半的线上事故。如果你哪天真把配置改崩了手边还有备份文件可以秒回滚那一刻你会感谢自己当初多敲的那条 cp 命令。