资讯详情

深入了解 · 专业解读

Nginx安全加固实战：从基础配置到反向代理与证书防坑指南

发布时间：2026/10/6 9:40:50
Nginx安全加固实战：从基础配置到反向代理与证书防坑指南 1. 先搞懂Nginx安全到底在防什么最近身边不少同事遇到同一个场景本地开发环境搭好了Nginx用“本机 虚拟机多端口”跑了好几套站点自定义域名也配置好了乍一看一切正常。可一旦把服务暴露到内网或者准备上线问题就来了——要么被安全测试扫出一堆高危项要么发现证书怎么配都不生效要么配置了反向代理去代理某个内部服务结果别人直接绕过了访问限制。说白了Nginx安全不只是“装个防火墙”或者“SSL证书能用就行”它是在管理一个门卫你允许谁进来、进来之后能碰到什么、每个进来的动作留没留下记录。Nginx在整个Web架构里的位置很特殊它通常是流量进入后端服务的第一道关口。正向代理、反向代理、负载均衡、静态文件服务哪个不经过它正因为卡在咽喉位置Nginx自身配置上的一个小疏忽就会变成整个系统的突破口。打个不太准确但很好理解的比方后端服务像家里的保险柜Nginx是房门。房门看着是关着的但如果门锁是个装饰品或者门后挂着备用钥匙那保险柜再结实也没意义。你要防的攻击者也不全是那种“拿着工具扫漏洞”的破坏者。更多时候是某个扫描器扫到你的版本号然后去漏洞库比对某个爬虫顺着你配置里的目录直接下载.env文件有人用try_files的路径穿越读到你服务器上的任意文件甚至可能就是一个员工在浏览器里试了一下代理后的内网服务发现根本没鉴权于是大家都来薅资源。这些场景在安全测试报告里非常常见但根子大多在Nginx配置上而不是业务代码上。所以这篇文章主要面向谁一类是刚接触Nginx、从下载安装配站点入门的开发者需要知道怎么把“能用”变成“安全可用”另一类是已经在用反向代理、计划把Nginx部署到容器或Kubernetes里的运维同学需要一份能直接参考的加固思路与排坑清单。我会把配置层面、HTTPS层面的细节、反向代理场景的常见漏洞、日志监控和容器安全问题都过一遍尽量把“为什么这么配”讲清楚。安全这件事越早想越省事。等出了事故再回去翻配置付出的成本可能是一晚上排查加整个团队的心理阴影。2. 配置文件层面的安全加固细节Nginx的安全属性绝大部分体现在nginx.conf的配置写法上。很多人的配置是从某个教程复制过来的能跑但完全不合格。我建议你按照下面几个方向逐条对着自己的配置过一遍。2.1 先隐藏版本号和大版本信息Nginx默认会在响应头里加上Server: nginx/1.24.0这样的信息这相当于告诉全世界你的软件版本。如果该版本存在已知漏洞攻击者根本不需要猜直接按漏洞库里的POC打就行。解决方式很简单在http块里加上server_tokens off;这个配置会让响应头的Server只显示nginx不再带版本号。同时Nginx默认的错误页底部也会带上版本号这里可以通过自定义错误页来进一步隐藏比如添加error_page 404 /404.html; error_page 500 502 503 504 /50x.html;配合server_tokens off错误页里基本就看不到版本相关信息了。为什么这点很重要很多自动化安全测试工具在做指纹识别时第一件事就是抓Server头。你隐藏了版本扫描器就无法快速定位漏洞库至少提升了一步攻击成本。2.2 限制HTTP方法和目录访问常见的安全扫描里会测试PUT、DELETE、TRACE这些方法是否被允许。默认Nginx会拒绝部分方法但不会拒绝PUT如果你用的是静态目录攻击者上传一个恶意文件到可写目录后果不堪设想。稳妥的做法是在server块或location块里做严格限制if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$ ) { return 405; }你可能会觉得用if在location里是anti-pattern但这个方法限制其实挺常用。更规范的做法是配合limit_exceptlocation /api/ { limit_except GET POST OPTIONS { deny all; } }目录访问的另一个大坑是开启目录列表。很多人为了调试方便在location里加了autoindex on;于是整个目录结构赤裸裸暴露给访问者配置文件、备份文件、内部文档全部可读。建议全局保持autoindex off;开过的赶紧关。接着是敏感文件的屏蔽。很多项目会在Web根目录下残留.env、.git/、*.sql、*.bak等文件。哪怕你已经删了也可能有几份编辑器自动生成的~结尾备份文件。这些在安全测试里属于“敏感文件泄露”问题可以干脆用一条正则拦截掉location ~* \.(env|bak|sql|tar|gz|log|git|svn)$ { deny all; return 404; }上面这段逻辑是先拒绝访问再返回404避免攻击者通过响应码知道文件存在。我实践下来这一条能消掉80%的敏感文件告警。2.3 限流给暴力破解和CC攻击台台阶下只要你的站点对外可访问就会有被爆破的风险。Nginx自带基于共享内存的接口限流模块可以针对客户端IP限制请求速率这是最基础但也最可靠的一道防线。先在http块定义限流区域limit_req_zone $binary_remote_addr zonelogin_limit:10m rate5r/s;然后在需要保护的location里引用location /login/ { limit_req zonelogin_limit burst10 nodelay; }这里zone的名字随便取10m表示共享内存大小可以在翻译期间容纳约16万个IP地址的会话状态。rate5r/s是限制平均每秒5个请求burst10允许短时间内的突发10个请求排队nodelay让排队请求立即处理而不是延迟但超出burst的请求会直接返回503。现在去看各种“Nginx安全加固题”无论是CTF还是实际基线检查基本都会考这一条。要注意的是限流值不是随便拍脑袋定的。你需要统计正常用户的请求节奏。比如登录接口用户手速再怎么快一秒两三次大多数情况已经算异常。如果站点有API接口建议区分接口的重要程度分别设限不能一个rate打天下。同时可以用limit_conn_zone限制同一IP的并发连接数limit_conn_zone $binary_remote_addr zoneperip:10m; limit_conn perip 20;这样能避免大量建立的空闲连接占用文件描述符。加了这些之后至少可以挡住低成本的暴力破解脚本。2.4 安全响应头成本最低的“护甲”安全响应头让浏览器来帮你执行部分安全策略意义非常大。接触过Web安全基线检查的人应该都熟悉下面这一组add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header X-XSS-Protection 1; modeblock always; add_header Content-Security-Policy default-src self; script-src self; object-src none; base-uri self always;X-Frame-Options防止你的页面被嵌套到恶意网站里做点击劫持X-Content-Type-Options防止浏览器对MIME类型进行猜测导致脚本注入Content-Security-Policy白名单控制浏览器只能加载允许的资源。配置CSP时别急着写死否则很容易把线上页面里的内联脚本全部禁用导致功能异常。我的建议是先上Content-Security-Policy-Report-Only观察几天告警再切到强制执行。这里有一个特别容易踩的坑add_header在location层和server层同时出现时如果location里没有写add_header那么它不会继承server层的头反而会清空。所以要么每层都写要么把安全头放进include文件里在所有server里统一引入。我自己是把常用安全头放在/etc/nginx/conf.d/security-headers.conf然后在每个server块中include一次省事且不会漏。3. HTTPS与SSL证书实战为什么替换证书总是不生效“此网站无法提供安全连接”“证书无效”“net::ERR_CERT_COMMON_NAME_INVALID”这类报错我相信每个人都在浏览器地址栏见过。当你确定证书没问题Nginx也没报错可浏览器就是不给面子八成是配置细节出了问题。3.1 SSL配置的基本姿势先看一个标准的SSL server块长什么样server { listen 443 ssl http2; server_name example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/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 off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; # ... }证书路径很关键。如果你的证书文件只包含域名证书没有包含中间证书很多客户端比如安卓手机上的部分浏览器、curl会报无法验证证书链。所以证书文件最好使用带fullchain的文件把主证书和中间证书按顺序合在一起。第二个容易忽略的问题是证书私钥权限建议设为600保证只有root可读否则Nginx主进程虽然能启动但其他人如果能读到私钥就完全失去加密的意义。3.2 “替换SSL证书不生效”的排查流程遇到替换证书不生效我见过不少人一上来就重启Nginx其实最该做的是按下面顺序排查首先确认证书和私钥内容是不是新的。用OpenSSL看指纹最准openssl x509 -in /etc/nginx/certs/fullchain.pem -noout -dates -fingerprint -sha256对比一下跟你在证书服务商那边看到的是否一致。如果一致继续往下。其次检查Nginx当前加载的配置路径。用nginx -T输出所有生效配置搜ssl_certificate看路径有没有被之后的配置覆盖。命名空间配置或者include顺序很容易让人犯迷糊以为改的是这个文件实际生效的是另一个同名的server块。然后执行重载而不是重启。很多人的习惯是systemctl restart nginx但Nginx支持热重载正确的做法是nginx -t nginx -s reloadnginx -t会告诉你语法错误reload会平滑加载新配置不会中断连接。如果你改完证书后仍用旧的进程运行很有可能是某个worker进程还没有领完新配置。虽然不常见但浏览器长连接保持情况下旧worker还在为某些连接服务此时刷新可能依然看到旧证书。等几秒或多刷新几次或者直接重启一次。最后用命令行测试curl -vI https://example.com 21 | grep -A 6 SSL connection看输出里证书的subject和issuer是否匹配新证书。如果返回链不完整再去核对fullchain内容。3.3 域名不过期也不对的NET::ERR_CERT_COMMON_NAME_INVALID这个报错翻译过来说是证书的“常用名”与访问的域名不匹配。常见原因有三个。第一你证书的SAN主题备用名称里没有包含当前访问的域名比如证书是给www.example.com签的但你用example.com访问。第二你用了IP地址访问证书只包含域名。第三多站点环境下server_name匹配规则不对浏览器连到某个server块时该块提供的证书和域名对不上于是报错。解决方案也很直接访问时用证书覆盖的域名如果是内网玩建议自己建CA签发带多个IP和域名的证书或者用自签名并导入信任如果只是本地开发可以配置浏览器跳过本地域名的HSTS。最不建议的是直接关闭证书校验这东西一旦关掉以后你访问什么都会看不出来。有的同学在JMeter里压测HTTPS接口时会遇到证书报错那不是Nginx问题是Java的信任库不认你的证书。把证书导入到JDK的cacerts里就行keytool -import -trustcacerts -alias example -file cert.pem -keystore cacerts这个操作只影响本机测试不影响线上安全。3.4 自动续期与证书安全现在大部分Nginx的SSL证书来自Let‘s Encrypt并提供certbot renew服务。注意续期之后一定要执行nginx -s reload让新证书生效。很多人配置了cron任务以为续了就行结果发现Nginx仍然用旧证书是因为证书文件路径被旧的绝对路径挂了出去。更稳的方式是用certbot的deploy hook在续期后自动reloadcertbot renew --deploy-hook systemctl reload nginx证书过期是Web安全里最基础但又最经常被忽略的问题。建议把证书监控接到你的监控系统里写一个脚本检查证书剩余天数低于30天就告警比靠脑子记靠谱。4. 反向代理场景下的攻击面与安全配置反向代理几乎是Nginx的招牌应用。代理静态文件、代理内部API、代理本地大模型服务场景很丰富。但代理模式最容易出现“Unproxied”的安全问题——你以为只暴露了一个接口实际上暴露了一个后门。4.1 代理静态文件和内网服务时怎么防路径穿越与任意文件读取很多人在Nginx转发静态文件时会这样配location /files/ { alias /data/www/files/; }如果alias后面带的路径末尾没有斜杠或者location的URI和alias拼接得不对就可能出现路径穿越。比如用户请求/files/../secret.txt如果Nginx把请求路径直接拼到磁盘路径上就会读到不该读的文件。Nginx本身会处理../但如果你用了proxy_pass到某个不规范的动态脚本就要小心拼接错误带来的任意文件读取。无论任何配置对外提供文件访问时最好遵循最小权限原则只暴露专门的下载目录且目录里不能有符号链接指向外部。还有一种情况你想代理内部另一台服务器的文件但后端服务器本身不带鉴权结果Nginx仅做透明转发把内网数据全部暴露出去。这种场景的修复思路不是在后端加鉴权而是在Nginx上加访问控制。你可以用IP白名单location /internal-files/ { allow 10.0.0.0/8; deny all; proxy_pass http://backend-server:8080/; }也可以加HTTP Basic认证或者更适合内部服务的是OpenID Connect接入统一登录。但如果你只是想快速保护暴露到公网的Ollama这类服务最简单的办法就是配置Header Token或密钥校验下面专门讲。4.2 反向代理Ollama等本地大模型服务时如何正确设置API KeyOllama默认监听127.0.0.1:11434没有任何鉴权。如果通过Nginx反向代理把它开放给局域网就等于允许局域网所有人调用你的模型接口包括监控非法调用的成本。社区里很多人会配置这样的代理location /ollama/ { proxy_pass http://127.0.0.1:11434/; proxy_set_header Host $host; }这种配置的唯一作用就是让远程可以访问Ollama接口安全性和裸奔没有区别。安全做法是加一层校验比如让所有请求携带一个预共享的Headerlocation /ollama/ { if ($http_authorization ! Bearer your-secret-token) { return 401; } proxy_pass http://127.0.0.1:11434/; }不过在location里使用if有时会产生意想不到的歧义所以更稳妥的方案是用map或访问阶段先做条件判断。这里给一个我用着一直没问题的写法server { listen 443 ssl; server_name ai.example.com; if ($request_uri ~* ^/ollama/) { set $verified 0; } if ($http_x_api_key your-strong-api-key) { set $verified 1; } if ($verified 0) { return 401; } location /ollama/ { proxy_pass http://127.0.0.1:11434/; } }为了不把密钥直接放在明文配置文件里你可以用Nginx的-a参数从环境变量读取或者用模板化工具渲染配置。如果还想更严格加上IP白名单、限制请求大小、启用访问日志确保每次调用都有记录。这样一个加了校验的反向代理配合TLS加密才能在公网上放心开放。比如你本地跑Cherry Studio这类AI工具远程连接Nginx代理后的Ollama就既安全又稳定。4.3 CORS配置里最常见的Nginx无效请求问题前端调接口时经常遇到“CORS policy”报错而错误信息可能就显示“Invalid CORS request”。这个是Nginx安全配置里特有的一种情况因为你把Origin请求头直接复制到了Access-Control-Allow-Origin响应头导致浏览器认为配置是动态的但又处理不好凭证标记。我们先看一个被不少人采用的错误配置add_header Access-Control-Allow-Origin $http_origin always;这种配置允许任意来源等于关闭了同源策略保护。如果站点需要携带Cookie或Authorization头还必须配合Access-Control-Allow-Credentials: true那么一个恶意站点发过来的跨域请求也能携带你的Cookie这就很危险了。如果只想允许几个固定域名正确做法是用map做白名单map $http_origin $cors_origin { default ; ~^https://(www\.)?example\.com$ $http_origin; } server { location /api/ { if ($cors_origin) { add_header Access-Control-Allow-Origin $cors_origin always; add_header Access-Control-Allow-Credentials true always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, DELETE always; add_header Access-Control-Allow-Headers Authorization, Content-Type, X-Requested-With always; } if ($request_method OPTIONS) { add_header Access-Control-Allow-Origin $cors_origin always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers Authorization, Content-Type always; add_header Access-Control-Max-Age 86400; return 204; } } }这里纵然用了if但对CORS预检场景是够用的。关键是当你使用了map后白名单之外的Origin请求头会映射成空字符串就不会拼进响应头了浏览器自然阻止跨域。需要说明的是使用通配符来做正则白名单时务必在域名结尾用$限制否则类似example.com.attacker.com的域名也能通过匹配。这就是很多Nginx配置里出现“invalid cors request”的基本原因——Nginx没有正确反射或校验Origin。4.4 反代时清理响应头避免泄露上游信息后端服务可能向下游传递一些敏感响应头比如X-Powered-By: Express、Server: Werkzeug/2.0、X-Backend-Server: 192.168.1.10等。攻击者可以利用这些信息推断后端技术栈和内网拓扑。在Nginx反向代理配置中可以用proxy_hide_header隐藏掉指定头部用proxy_pass_header保留允许的头部。location /app/ { proxy_pass http://backend:8080/; proxy_hide_header X-Powered-By; proxy_hide_header X-Backend-Server; proxy_hide_header Server; }同时还要设置proxy_set_header来控制传给上游的请求头。默认情况下Nginx会带上Host有时你希望转发原始域名有时你希望转发后端期望的域名。注意不要无条件透传客户端的X-Forwarded-For如果你把客户端的IP记录下来一般用这个proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;这里$proxy_add_x_forwarded_for会在客户端传入的XFF后面追加当前IP。但如果你不加保护直接把整个头转发给后端攻击者可以伪造内网IP。如果确实需要取真实客户端IP建议配合real_ip模块从可信代理层读取而不是直接信任XFF。5. 安全监控、日志分析与容器化部署的坑配置加固之后如果没有监控等于闭着眼睛开车。安全不只是事前预防更要能够发现“正在进行时”的攻击。5.1 从访问日志里看出攻击特征Nginx的日志非常重要但默认日志格式信息不够最好自定义log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for rt$request_time uct$upstream_connect_time uht$upstream_header_time; access_log /var/log/nginx/access.log main;有了时间消耗字段你还能顺便做性能分析发现问题请求。安全观察方面我平时会重点看几类异常大量来自同一IP的404访问可能是扫描器在探测路径。请求URL携带/etc/passwd、../、?id1 and 11等特征可能在尝试注入。大量HEAD请求加上常见后台路径说明在用工具批量探测。User-Agent是sqlmap/1.6、Nuclei、masscan等扫描器特征。请求方法非常规比如TRACE、PUT、PATCH。配置日志后再配合定时分析脚本每天扫一次高危IP效果很好。尽量不要让日志文件无限膨胀用logrotate定期切割。很多系统默认已经带/etc/logrotate.d/nginx但要确认打开的是压缩和定时任务。5.2 用Zabbix监控Nginx不只盯CPU还要盯连接数和错误码Zabbix监控Nginx是很成熟的方案。前提是Nginx开stub_status模块然后在server块暴露一个仅限本机访问的status接口。不要直接暴露给公网否则普通人也能看到你的连接统计信息虽然危害不大但没必要location /nginx_status { stub_status; allow 127.0.0.1; deny all; access_log off; }然后在Zabbix Agent里用nginx_status模块收集active connections、accepts、handled、requests这些关键计数。结合告警规则比如每分钟错误次数超过阈值、活动连接数骤升很可能就是被刷了。另一种常见监控手段是解析error.log提取warn、critical级别的日志条数。注意Nginx日志里的[crit]级别往往和资源耗尽、worker进程挂掉相关必须重点关注。安全监控不是搭好就能睡大觉你还要定期回顾这些数据。特别麻烦的一点是很多攻击流量伪装成正常请求单看几分钟内看不出异常但连续几小时低频率请求某个接口是人在手工测漏洞自动告警往往发现不了。这时候就需要更持久的日志分析比如统计每天出现频次最高的URL和IP这个我不展开但做安全审计基本绕不开。5.3 容器化Nginx镜像安全与容器运行时安全越来越多的Nginx跑在Docker或Kubernetes里。容器带来的安全问题和物理机不一样这里只讲几个我踩过的坑。第一个坑是用默认镜像直接跑。官方nginx镜像默认以root运行容器的root和宿主机的root有密切关联一旦容器被攻破越权风险很高。尽量使用nginxinc/nginx-unprivileged这类非root镜像或者在Dockerfile里指定用户FROM nginx:1.24-alpine RUN sed -i s/listen .*;/listen 8080;/ /etc/nginx/conf.d/default.conf USER 101:101 COPY nginx.conf /etc/nginx/nginx.conf然后宿主机映射端口时将80映射成8080这样容器内部不需要特权端口。在Kubernetes里需要给Pod配置securityContext限制能力禁用权限提升securityContext: runAsNonRoot: true runAsUser: 101 allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [ALL]readOnlyRootFilesystem: true会让配置目录和日志目录都成为只读需要在挂载或者emptyDir卷里解决日志和缓存写入问题。好处是攻击者即使拿到shell也没法写文件至少不能改权限和植入持久化后门。第二个坑是挂载配置目录时出现的“conf.d挂载报错”。很多同学用nginx:alpine镜像时会把宿主机上的conf.d目录挂载进去。结果容器一启动就报错通常是挂载目录里没有default.conf或者目录权限不是101:101导致Nginx worker无法读取配置。我实际调查过的案例里最多的是因为挂载时把宿主机目录的结构弄得和镜像内不一致。解决方法很朴素nginx -t在宿主机预先验证配置确认挂载路径正确目录内有且仅有.conf文件。如果你用Kubernetes更推荐用ConfigMap挂载到/etc/nginx/conf.d/并且挂载路径要精确不要整个覆盖目录。第三个坑是镜像标签。不要在Dockerfile或K8s部署里使用nginx:latest或nginx:stable应该固定到具体小版本比如nginx:1.24.0-alpine。latest标签会滚动更新可能导致配置不兼容或安全问题。同时建议用trivy这类镜像扫描工具定时扫描Nginx镜像注意扫描结果不光是Nginx自身还要包含基础的操作系统包漏洞。5.4 快速自测用命令行做一次安全体检没有条件上专业扫描器时用几条命令也能初步判断Nginx是否“结实”。首先看响应头curl -I https://example.com观察Server头是否带版本Strict-Transport-Security、X-Content-Type-Options等安全头有没有返回。其次用OpenSSL测试TLS协议和证书链openssl s_client -connect example.com:443 -servername example.com -preferred_versions TLSv1.3再看是否支持老旧的TLS1.0openssl s_client -connect example.com:443 -tls1 -no_ticket如果返回no protocols available说明低版本TLS已禁用很好。然后试着访问常见敏感路径curl -o /dev/null -s -w %{http_code} http://example.com/.git/config curl -o /dev/null -s -w %{http_code} http://example.com/.env返回404基本正常。最后执行nginx -t确保配置语法无误检查配置文件里的关键项是否都符合预期。这只是基础体检但每次配置变更后做一遍能挡住不少低级失误。6. Nginx安全高频踩坑与排查速查表下面把这几类问题整理成一张速查表全是实际运维和开发过程中频繁出现的。有对照表不仅方便排查也适合用作代码审查的checklist。现象常见原因处理方式替换证书不生效证书链不全 / 路径未reload / 浏览器缓存nginx -t nginx -s reload用curl -vI核对证书指纹访问HTTPS报NET::ERR_CERT_COMMON_NAME_INVALID域名与证书SAN不匹配 / server_name没对上检查证书域名用域名访问重新签发带对应域名的证书配置了安全响应头但curl看不到add_header在location层被覆盖用include统一引入避免同层覆盖CORS预检报invalid requestOrigin没有白名单校验 / OPTIONS返回异常用map固定源白名单不要反射任意Origin反代到内网服务永远401上游接口本身有鉴权 / Header没透传确认存活和鉴权方式在Nginx层透传或替换Header日志里大量扫描器UA公网暴露太彻底安装WAF或限制访问频率开启日志分析Nginx在容器里无法启动挂载目录权限不对 / conf.d没有配置入口检查目录属主和挂载模式先nginx -tDocker容器root用户运行镜像默认用户是root换nginx-unprivileged或指定非root UID这张表不是终点安全配置的验证要循环做。你可以在本地建一套“本机虚拟机 多端口Nginx开发环境多站点自定义域名配置”每个站点单独一个server块然后自己在浏览器里模拟各种异常访问。把所有非必要的功能关掉让每个暴露的端口都能说清楚是干什么用的。如果说不清楚这个端口就不该开。写在最后我个人在实际操作中最大的感受是Nginx安全不是在某个大版本发布后一次性变好的而是靠一条条配置和一次次reload堆出来的。你对这个门卫越尊重真正出事后的代价就越小。如果你只打算记住一件事那我建议是任何对Nginx配置的修改先跑nginx -t再reload然后用curl -I看响应头最后看一眼错误日志。这套流程虽然朴素但我见过太多线上事故都是因为改配置时少验证一步。最后再分享一个小技巧在配置文件的注释里写好“这条配置为什么这么写”下次你或者接手的人来排查时会感谢你当初的这几行字。

相关新闻