小鹅通最近在折腾家里那台NAS的时候，被几个问题轮番折腾到半夜：想统一用域名和HTTPS访问各类服务，结果有的服务是HTTP、有的要WebSocket长连接，还有几个套件的路径映射怎么配都别扭。折腾完这一圈，最大的感受是，Nginx反向代理这块属于典型的“配一次、能跑好几年”的活，但前提是第一次就得把原理和细节搞清楚，不然日后每加一个服务就要重新踩一遍坑。
这篇文章就把我实测过的一套完整方案拆开讲透：包含HTTP强制跳HTTPS、WebSocket长连接穿透、NAS多服务转发，以及部署后怎么验证、怎么排查。文章里有完整可抄的配置，也有配置背后为什么要这么写的逻辑。不管你是刚接触Nginx的小白，还是已经在生产环境里跑Nginx的运维，只要你用Nginx代理过带WebSocket的服务、给NAS套件配过子路径，这篇文章里应该都有你用得上的东西。
1. 为什么要在前面加一层Nginx：三个不解决就反复踩坑的场景
先说点实在的。很多人一开始觉得反向代理是“大厂才需要的东西”，自己家里一台NAS、几个服务，直接IP加端口访问不就行了？理论上确实行，但只要你手里的服务超过三个，这套“原始方案”就会开始暴露问题，而且问题全是连续性的：端口记不住、HTTPS证书没法统一、服务地址一变就全乱套。
1.1 服务多了之后，端口号就是第一个失控的地方
假设你有一台群晖或者自己攒的飞牛NAS，上面跑着文件管理、下载工具、家庭相册、离线下载、监控面板，每个服务一个端口。今天要用下载工具，得记住8080是它；明天看监控，得记住9000是它。如果还有一台云服务器上挂着API服务，又是另一个IP加端口。这还只是“知道地址”的问题。
更麻烦的是，很多服务默认监听在HTTP上，直接把端口暴露到公网的话，等于把明文流量铺在网络上让人看。长期用下来，你还会遇到“某个服务不知道为什么就是连不上”的排查地狱：是端口冲突？是防火墙拦了？是服务进程挂了？没有统一入口的时候，每排查一个问题都要从头捋一遍网络链路。
反向代理解决的就是这一整层问题：所有外部请求统一打到Nginx的80/443端口，由Nginx按域名或路径把流量分发到内网不同服务的实际IP和端口上。对外你只需要记住一个入口地址，服务怎么变端口、怎么换机器，对内改动就行，外部无感。
1.2 HTTPS只在网关做一次，比每个服务各搞一套省心得多
第二个痛点来自HTTPS。现在越来越多场景要求强制HTTPS：有些API回调要求必须是HTTPS地址、PWA应用要求安全上下文、现代浏览器的很多高级特性也需要HTTPS才开放。如果直接访问NAS的HTTP端口，这些问题会一个接一个冒出来。
你可以给每个服务都单独配证书，但这种做法在现实里很难维持：证书续期要挨个处理，每个服务的监听端口还要改，内网服务之间互相调用时证书校验又是一堆破事。最常见的首选方案是在Nginx这一层统一终结HTTPS：证书只装一份在Nginx上，外部用HTTPS和Nginx通信，Nginx和内部服务之间走内网HTTP。这样证书的管理半径被压缩到一个入口里面，后续再加服务时不需要再动证书。
1.3 路径区分：一个入口访问多个应用
还有一类需求是“同一个域名下，用路径区分服务”。比如 https://my.domain.com/ 是NAS主界面，https://my.domain.com/download/ 是下载工具，https://my.domain.com/photos/ 是相册。Nginx通过location块来匹配不同的路径前缀，再把请求转发给不同的后端服务。
这种方式最典型的应用场景就是NAS：群晖的Web服务、套件中心里的各种套件，很多都希望挂在同一个反代域名下面。但路径转发恰恰是Nginx配置里最容易被忽略“末尾斜杠”差异的地方，一个斜杠的差别就能导致404或者页面样式全丢。这个我在第5章里会专门拆开说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把最简反向代理跑通：从安装到第一份可用的server块
不管后面要做多复杂的配置，第一步永远是先让Nginx跑起来，并且能成功代理一个最简单的服务。
2.1 安装Nginx：发行版仓库里的就够用了
在Debian/Ubuntu系统上安装Nginx非常简单：
bash复制sudo apt update
sudo apt install -y nginx
安装完后，systemctl status nginx 看一下状态，默认配置文件在 /etc/nginx/nginx.conf，主配置文件里一般会引入 /etc/nginx/conf.d/*.conf 或者 /etc/nginx/sites-enabled/*（视发行版而定）。我习惯把每个站点独立成一个文件放在 conf.d 下面，比如 conf.d/reverse-proxy.conf，这样结构清晰，改一个服务不会影响其他配置。
CentOS/RHEL系统上用yum/dnf装也一样，路径略有差异，但核心配置语法一致。
提示：如果你用的系统自带Nginx版本太老（比如CentOS 7带的1.20左右），建议配一下Nginx官方源装新版，老版本对HTTP/2、WebSocket支持的默认参数有些跟不上，后续配起来总是差口气。
2.2 最小可用的server块配置
假设你的NAS内网IP是 192.168.1.100，Web界面跑在 5000 端口，现在想让外部通过 https://home.example.com 访问它。一个最基础的配置是这样：
nginx复制server {
listen 80;
server_name home.example.com;
location / {
proxy_pass http://192.168.1.100:5000;
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;
}
}
这段配置的核心就是这个 location / 块：所有匹配到的请求都会被Nginx转发给 http://192.168.1.100:5000。加上的三个proxy_set_header是常规操作，它们的作用是让后端服务知道原始的域名、客户端真实IP、以及原始请求是HTTP还是HTTPS。很多后端程序在生成链接时依赖这些头信息，不设置的话会出现页面里跳转到内网IP、或者误判为HTTP请求之类的问题。
写完修改后用 nginx -t 检查语法，然后 systemctl reload nginx 热加载。这一步能通，说明反向代理最核心的链路已经通了。
2.3 proxy_set_header里的三行是多数问题的根源
很多人在这一步就遇到过“反代过去页面能开，但资源加载失败”的怪问题，症状五花八门，根源却常常出在header上。
第一行 Host $host 是最关键的。Nginx默认不带Host头时，很多虚拟主机类型的服务会返回默认站点而不是你想要的站点，或者因为Host不匹配直接给你403。设成 $host 可以让后端服务看到浏览器里输入的域名。
X-Real-IP 和 X-Forwarded-For 是为了把真实客户端IP透传给后端。如果不设置，后端程序里的IP记录永远是Nginx服务器的内网IP，日志、审计、封IP策略全部会失灵。X-Forwarded-Proto $scheme 则是用来告知后端“用户实际是用HTTPS访问的”，很多应用根据这个头来生成独立的回调地址，少了它，回调地址可能变成HTTP，最后引起登录跳转循环。
踩坑经验：header的顺序不影响功能，但不要重复设置同名header。如果你在location里又套了一层location，子块会继承父块的proxy_set_header，但当你在子块里重新定义了某个header之后，它会完全覆盖父块的同名定义，不会做合并。
3. HTTPS强制跳转：证书落地到301重定向的完整链路
一旦基础反代跑通，下一步就是把HTTPS接管过来。这一块如果只按网上的“复制粘贴大法”做，通常也能通，但遇到细节问题就抓瞎。我拆开讲一下每一环的作用，以及最容易踩的坑。
3.1 证书文件从哪里来、放在哪里
证书现在获取已经很便宜了，有条件的直接申请Let's Encrypt免费证书，用certbot自动续期；云厂商的免费证书也是一个路子，一年一换也能接受。内网环境不方便用公网CA的，可以用自签证书，但要注意浏览器会报不安全警告，有些场景下可以用内部CA并把它导入各设备信任链，效果也不错。
证书拿到后是两部分文件：证书链（一般是 .pem 或者 .crt）和私钥（.key）。放到Nginx能读到的路径，比如 /etc/nginx/ssl/，然后在server块里指向它们：
nginx复制server {
listen 443 ssl;
http2 on;
server_name home.example.com;
ssl_certificate /etc/nginx/ssl/home.example.com.pem;
ssl_certificate_key /etc/nginx/ssl/home.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}
listen 443 ssl 和 http2 on 这两行，老版本Nginx写法是 listen 443 ssl http2;，新版本（1.25.1+）推荐拆开写，语法更清晰。注意证书链文件需要包含中间证书，否则有些客户端会校验失败。如果不知道怎么判断，直接把证书内容粘贴到ssl_certificate文件里，把CA给你的完整链整体放进去，一般不会有错。
3.2 443监听与80跳转的写法差异
要让所有访问HTTP的人自动跳到HTTPS，80端口的server块需要做跳转。多数教程会告诉你用rewrite：
nginx复制server {
listen 80;
server_name home.example.com;
rewrite ^(.*)$ https://$host$1 permanent;
}
这个写法能跑，但效率不是最优。更推荐用 return 301：
nginx复制server {
listen 80;
server_name home.example.com;
return 301 https://$host$request_uri;
}
区别在于：return 直接终止请求并返回301，Nginx不执行正则匹配，性能更高；rewrite 会走一遍完整的重写引擎，如果server块里还有其他location规则，可能出现意料之外的连锁匹配。
另一个容易被忽略的点是：return 301 要放在80端口server块的顶层，而不是放在某个location内部。如果你放在顶层，所有匹配到该server_name的请求都会跳转；放在location里，则只有该路径下的请求才会跳转，其他路径会漏掉。
3.3 一个容易被忽视的坑：HSTS对自签证书和内网IP不友好
很多配置教程会在HTTPS server块里加一段HSTS：
nginx复制add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
它的作用是告诉浏览器“以后只能通过HTTPS访问这个域名”，浏览器会记住这个策略。这个头在公网正式域名上很有价值，能防止降级攻击。但在某些场景下它会变成坑：如果你用的是自签证书，或者你的域名后面会换到新的证书上，一旦浏览器缓存了HSTS策略，你再想用HTTP访问本机或者内网IP测试，浏览器会直接拒绝，而且很多浏览器没有快捷方式绕过，只能手动清站点数据。
我的习惯是：公网正式域名且证书续期稳定的服务，才开HSTS；内网测试、自签证书、经常换IP/域名的环境，先不开，等稳定了再开。这个取舍比网上那些“一刀切配置”要实用得多。
4. WebSocket代理的翻车现场：从配置头到超时参数的逐个排查
HTTPS做完了，接下来是重头戏——WebSocket。在Nginx反代里，WebSocket是最容易出诡异问题的场景，而且报错信息往往五花八门，网上搜出来的答案也是各说各话。
4.1 WebSocket握手为什么会被代理“掐断”
WebSocket和普通HTTP最大的区别在于：连接建立后不是发完即断，而是需要保持一段长连接，双向推送数据。这个“建立”过程靠的是HTTP升级协议：客户端发一个带 Upgrade: websocket 和 Connection: Upgrade 头的HTTP请求，服务器如果同意，就返回101状态码，之后这条TCP连接就变成WebSocket通道。
问题就出在这个“升级”上。Nginx默认作为HTTP代理时，会剥离掉包含 Upgrade 和 Connection 这两个头，因为Nginx在按普通HTTP请求去转发。后端拿到的请求没有升级头，自然就当成普通HTTP请求处理了，握手失败，客户端就会报类似“WebSocket connection failed”或者“stream disconnected before completion”的错误。
要让Nginx放行升级头，需要显式声明：
nginx复制proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
第一行的意思是“如果原始请求里有Upgrade头，就原样传递给后端”；第二行是“把Connection头强制设为upgrade”。这两行是WebSocket反代的核心所在。
4.2 一个能稳定跑通WS/WSS的完整location块
只加上面那两个头还不够，WebSocket长连接还涉及超时问题。Nginx默认的 proxy_read_timeout 是60秒，意思是后端60秒内如果没发数据给Nginx，Nginx就会主动断开连接。而WebSocket场景下，长时间无消息是常态，心跳间隔可能都超过60秒，所以必须把这个超时调大。
给一个完整的location块：
nginx复制location /ws/ {
proxy_pass http://192.168.1.100:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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_read_timeout 3600s;
proxy_send_timeout 3600s;
}
这里有一个隐蔽但很关键的细节：proxy_http_version 1.1。默认情况下Nginx代理后端请求用的是HTTP/1.0，而HTTP/1.0没有标准的Upgrade机制，WebSocket握手依赖HTTP/1.1，不显式指定的话，即使你配了Upgrade头也可能不生效。这一行是很多WebSocket配置里最后卡住的那颗螺丝。
proxy_read_timeout 和 proxy_send_timeout 设多少合适？如果业务里自带心跳机制，客户端每30秒或60秒会发ping，那设300秒都够。如果没有心跳，建议设3600秒，并且在应用层做好断线重连机制，这样即使连接被Nginx断了，客户端也能自己恢复。
4.3 定位“WebSocket closed by server”的排查链路
我在实际部署里遇到过几次客户端报类似 stream disconnected before completion: websocket closed by server before res 的错。这个报错翻译过来就是“WS连接还没完成就被服务端关闭了”，但谁才是“服务端”？可能是Nginx，也可能是后端程序。排查链路我建议按这个顺序来：
第一步，先绕过Nginx，直接连后端WebSocket服务。如果后端回应正常，说明问题出在Nginx层；如果后端也报错，就得先修业务。
第二步，打开Nginx的error.log和access.log，错误日志里如果有 upstream prematurely closed connection，说明Nginx向后端转发后，后端的WS连接被关闭了；如果看到 upstream timed out，说明是超时参数设得太短。
第三步，确认前端代码连接的是 ws:// 还是 wss://。Nginx开了HTTPS之后，WebSocket的地址要从 ws:// 改成 wss://，并且路径要和location匹配。很多人前端代码里写死了IP加HTTP端口，一换到反代环境就忘了同步改协议，这个错误日志里很难直接看出来，最坑。
第四步，检查你用的WebSocket客户端库是否在代理模式下默认带了额外的路径前缀。很多框架（比如Spring的WebSocket、Python的websockets）对子路径的处理方式不同，location匹配的是 /ws/，但客户端可能发的是 /ws，斜杠差异会导致匹配失败。
经验之谈：Nginx配WebSocket，最先看三样——Upgrade头、Connection头、proxy_http_version。三样都对，90%的问题都能解决。剩下10%里，一半是超时，一半是前后端路径不匹配。
5. NAS服务的多层转发：套件映射、路径改写与端口冲突
前面说的都是基础的反代原理，现在回到NAS这个具体场景来组合应用。NAS之所以是反向代理的“重灾区”，是因为一个NAS上往往同时跑着十几个服务，有系统自带的，还有Docker跑的，每个服务的URL设计方式还不一样。
5.1 群晖/飞牛这类NAS为什么需要反代
群晖的DSM默认跑在5000端口（HTTP）和5001端口（HTTPS），飞牛NAS的Web界面也在特定端口上。直接暴露这些端口到公网，不仅端口号不好看，而且DSM这种重型管理界面暴露在公网，扫描器天天都会来光顾，暴力破解风险很高。
用Nginx反代后，你的NAS管理入口就变成一个普通的443端口下的路径或者一个独立子域名。而且Nginx这一层可以做访问控制、限速、拦截恶意请求，比让NAS的每个端口都裸奔要稳得多。如果你有公网IP或者云服务器，Nginx反代还能解决“多个服务都想用443端口”的矛盾：以前如果你有DSM、相册、下载工具三个Web服务都想要HTTPS，端口会打架；现在所有HTTPS流量都进Nginx，由Nginx按域名或路径分流到不同内部端口。
一个实际的群晖反代配置示例：
nginx复制server {
listen 443 ssl;
http2 on;
server_name nas.example.com;
ssl_certificate /etc/nginx/ssl/nas.example.com.pem;
ssl_certificate_key /etc/nginx/ssl/nas.example.com.key;
location / {
proxy_pass https://192.168.1.100:5001;
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;
}
}
这里有个和普通HTTP服务不一样的点：如果NAS后端本身就是HTTPS（比如群晖的5001端口），那么proxy_pass里的协议也要写 https://，并在后面加上 proxy_ssl_verify off; 来跳过证书校验（因为内网NAS的证书通常不被公网CA信任，Nginx默认会校验证书导致转发失败）。如果跳过证书校验让你觉得不安全，也可以把NAS的CA证书添加进系统信任库，不过配置成本更高，家庭环境里一般不值得。
5.2 带路径前缀的套件转发，该不该加结尾的斜杠
这是NAS反代里最容易踩糊的一个点。假设你的NAS上跑了一个下载工具，它自己的Web界面监听在 192.168.1.100:8080，你想通过 https://nas.example.com/download/ 来访问它。配置写出来是：
nginx复制location /download/ {
proxy_pass http://192.168.1.100:8080/;
...
}
注意这个 proxy_pass 末尾的 /。它代表“把 /download/ 前缀剥离掉，剩下的部分拼到 http://192.168.1.100:8080/ 后面”。比如浏览器请求 https://nas.example.com/download/login，Nginx实际转发给后端的是 http://192.168.1.100:8080/login。
如果你把末尾的 / 去掉，写成 proxy_pass http://192.168.1.100:8080;，那么Nginx会把完整路径原样转发，后端收到的还是 /download/login，如果后端不知道 /download 这个前缀，就会返回404。
反过来也有问题：很多前端应用生成静态资源链接时用的是根路径（比如把CSS文件指向 /static/app.css），如果你是用子路径访问它，这些资源请求就会落到Nginx的 /static/ location里而不是 /download/ 里，结果就是页面HTML能打开但样式全乱。这个问题的根因在于后端应用本身不知道自己在子路径下运行。解决方式要看后端应用支持不支持“根路径前缀”配置——有些应用有 base-path 或 Prefix 配置项，设成 /download 就行；如果不支持，就得用 sub_filter 把HTML里的 /static/ 替换成 /download/static/。这个手段比较暴力但有效，代价是会增加一点CPU开销，而且只对HTML/JS/CSS生效，对API里的绝对路径无能为力。
经验之谈：如果后端是Docker跑的，优先看Docker镜像或容器环境变量里能不能配置“URL前缀”或“BasePath”，很多现代镜像都支持，配好之后反代这边只需要一个干净的proxy_pass就行。这是最省心的方案，不要一上来就上sub_filter。
5.3 NAS上Docker套件的WebSocket依赖
NAS上跑的很多套件其实是带WebSocket的。比如qBittorrent的Web UI、某些实时监控面板、协同编辑工具，都会用WebSocket推送数据。如果你在Nginx里给这些套件配了子路径反代，却没有在对应location里加上第4章说的WebSocket专用配置，症状往往是：Web界面能打开、列表能加载，但刷新很慢、操作完不实时更新、事件推送经常断。
给一个NAS上Docker套件的完整反代示例，把HTTPS、子路径、WebSocket三件事合在一起：
nginx复制location /qb/ {
proxy_pass http://192.168.1.100:8081/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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_read_timeout 3600s;
}
这段配置是把子路径前缀、WebSocket升级头、超时设置全部融合在一起的典型样本。实际部署时，如果你发现套件能打开但实时推送不行，先用浏览器的开发者工具看Network面板，找到WebSocket请求（一般是 ws:// 或 wss:// 开头的请求），查看它返回的状态码是101还是其他值，以及响应头里有没有 Upgrade: websocket。这一步能让问题定位变得非常快。
5.4 端口冲突：多个服务抢同一个入口
NAS场景下有个很实际的问题：Docker容器太多了，端口不好分配。有些容器默认占用端口是一样的，比如两个应用都用8080，你必须给其中一个改端口映射。在这种“容器端口变来变去”的背景下，Nginx反代的价值反而更突出了——Nginx这里只需要改一行proxy_pass的端口，外部访问地址完全不变。
我还遇到过一种情况：NAS自己的Web服务占用5000/5001，但某个Docker容器也想用5000，容器启动时端口绑定失败。这种冲突查起来比较费劲，建议用 netstat -tlnp 或 ss -tlnp 看一眼当前监听端口，再做分配。端口规划这件事，在NAS上尤其重要——别把端口随手分配，最好定个规则，比如Web应用用80xx段、数据库用54xx段、中间件用63xx段，这样以后看配置一眼就能判断是什么服务。
6. 部署完别急着收工：验证方法、日志排查与安全加固
配置写完了、reload了、页面能打开了，很多人就觉得大功告成。但反向代理这层网关上，有一些问题并不会在第一次打开页面时暴露，要等到某些特定操作时才突然冒出来。所以部署完成后，我建议按下面的方法做一轮系统验证，顺便把安全基线补上。
6.1 用curl模拟请求验证配置是否生效
用curl验证反向代理是最直接的方式，它能帮你绕过浏览器缓存和插件干扰，看清真正的响应链路。
检查HTTPS跳转是否生效：
bash复制curl -I http://home.example.com
预期返回 301 Moved Permanently，并且 Location 头指向 https://home.example.com/。如果没有跳转，检查80端口的server块是否匹配到了这个域名。
检查HTTPS证书是否正常：
bash复制curl -I https://home.example.com
预期返回200或302（取决于后端），并且没有任何证书错误。如果你看到 SSL certificate problem，先检查证书文件路径和权限，再检查证书链是否完整。
检查WebSocket握手是否正常：
bash复制curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" https://home.example.com/ws/
如果后端配置正确，会返回 HTTP/1.1 101 Switching Protocols。如果返回404，说明location路径没匹配上；如果返回426或者其他错误，检查后端服务和proxy_pass路径。这条命令不一定能建立完整的WebSocket连接（因为缺少后续的握手帧），但足以验证Nginx这一层是否放行了升级头。
检查代理头信息是否正确透传：
bash复制curl -I https://home.example.com/api/ping
然后去后端服务的日志里看收到的 X-Real-IP 是不是客户端真实IP，而不是Nginx服务器的内网IP。
6.2 error.log里最常见的三类报错
Nginx的日志文件位置因系统而异，Debian/Ubuntu一般在 /var/log/nginx/error.log，CentOS/RHEL在 /var/log/nginx/error.log 也一样。排查问题时的标准动作是 tail -f 观察日志，然后复现问题。
我在实际运维中遇到的报错大概可以归成三类：
第一类是 upstream timed out。表现为代理请求偶尔超时。原因通常是后端服务响应慢，或者反向代理的超时参数设得太短。排查时先看后端日志，确认是不是业务本身慢，再决定是调大 proxy_read_timeout/proxy_connect_timeout 还是优化业务。
第二类是 no live upstreams while connecting to upstream。意思是Nginx尝试连接后端所有可用节点都失败。常见原因是后端服务宕机、防火墙拦截了Nginx到后端端口的流量，或者后端IP/端口配置错误。用 curl 直接在Nginx服务器上访问后端地址，能快速确认问题出在哪一层。
第三类是 SSL: error:0A000126:SSL routines::unexpected eof while reading。这类报错多与HTTPS证书或SSL握手异常有关。如果只在个别客户端出现，先检查客户端系统时间是否准确，再检查证书链是否完整。如果是自签证书场景，检查客户端是否信任了该CA。
6.3 暴露到公网前一定要做的三件事
如果你的反代入口会暴露到公网（哪怕只是开放了443端口），下面三件事建议在部署第一天就做掉，别等被攻击了再后悔。
第一，限制Nginx只响应配置过的域名。没配过的域名和直接用IP访问的请求，应该返回444（Nginx直接断开连接）或者一个明确的错误页。做法是在配置文件里加一个默认server块：
nginx复制server {
listen 80 default_server;
listen 443 ssl default_server;
ssl_certificate /etc/nginx/ssl/default.pem;
ssl_certificate_key /etc/nginx/ssl/default.key;
return 444;
}
这个默认server块会捕获所有没有匹配到其他server_name的请求。公网扫描器最常用的就是直接扫IP和随机域名，你这样做能把扫描流量直接掐掉。
第二，在Nginx层做IP访问频率限制。比如限制每个IP每秒钟最多多少个请求：
nginx复制limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
server {
...
location / {
limit_req zone=general burst=20 nodelay;
proxy_pass http://192.168.1.100:5000;
...
}
}
这个配置的作用是防止某个IP短时间内发出大量请求打爆你的NAS。burst=20 nodelay 表示允许瞬时超过限制一定量的请求，超过的排队，队列也满了就拒绝。实际使用时根据业务情况调整rate，太严格会误伤正常用户，太宽松又失去意义。
第三，定期看访问日志。Nginx的access.log里有很多信息，观察异常请求是最直接的发现手段。比如大量404、大量带奇怪User-Agent的请求、同一个IP反复尝试不同路径，这些都是扫描或攻击的早期信号。日志建议至少保留30天以上，云服务器的话可以用logrotate定期切割，避免日志文件无限增长把磁盘塞满。
经验之谈：NAS这类设备本身性能有限，把它直接暴露在公网上不是一个好选择。让Nginx做入口、NAS做内网服务，两者通过内网通信，是目前比较稳妥的架构。你再配合fail2ban之类的工具，把暴力破解IP自动拉黑，安全水位会高很多。
最后再分享一个我在实际使用中的小技巧：任何对Nginx配置的修改，都先在本地用 nginx -t 做语法检查再reload，这能避免很多因为手滑打错一个字符导致整个站全部502的尴尬。另外，每次改配置之前，把当前可用的配置备份一份到Git仓库，不管做多少次改动都能随时回滚，这对反复调优的场景来说，价值极高。