Nginx 反向代理入门：把后端服务安全地暴露到公网

很多新手第一次把自己写的后端服务放到公网上时，做法往往很直接：在服务器上把应用端口直接对外开放，域名解析过去就能访问。这样做虽然能跑起来，但后端进程直接面对互联网，风险和维护成本都不低。Nginx 反向代理就是解决这个问题的常用入口：让 Nginx 站在最前面接收请求，再把请求转发给内部的后端服务。

一、反向代理到底是什么

先区分两个容易混淆的概念。正向代理是代替客户端去访问目标，目标不知道真正的客户端是谁；反向代理则是代替服务端接收请求，客户端不知道真正干活的是哪台后端机器。用户在浏览器里访问的是域名和 Nginx 的地址，Nginx 再根据规则把请求交给本机或者内网的其他服务。

一个最简单的请求链路是这样的：浏览器访问域名，解析到服务器的公网地址，Nginx 在 80 或者 443 端口接住请求，根据 location 规则转发到 127.0.0.1:8080 或者内网地址上的应用，最后把应用的响应原样返回给浏览器。整个过程中，后端端口不需要对外开放，客户端也看不到后端的真实拓扑。

二、为什么要多这一层

第一是隐藏与隔离。后端可以直接只监听本地回环地址或者内网地址，数据库、管理后台、调试接口等敏感入口不再直接暴露在公网。即使某天后端换了端口、换了语言、换了部署方式，对外地址和域名也可以保持不变。

第二是统一入口与灵活路由。一台服务器上可以同时跑网站、接口服务、静态资源和管理端，Nginx 用 server_name 区分域名，用 location 区分路径，把不同路径交给不同的后端。例如把 /api/ 交给接口服务，把静态文件直接由 Nginx 返回，就不用为每个服务单独占用公网端口。

第三是安全与性能的集中处理。HTTPS 证书可以只在 Nginx 上配置和续期，后端继续走明文内网通信；限流、超时、请求体大小限制、访问日志、缓存和压缩也可以在入口层统一做。这样后端代码更干净，安全策略也更容易复查。

第四是扩展性。以后需要扩容时，可以在 Nginx 后面挂多个后端实例做负载均衡；需要灰度时，可以按权重或者路径把一部分流量切到新版本。这些能力都不需要改动客户端的访问方式。

三、一个最简可用的配置

下面是一个入门示例，假设后端跑在本机的 8080 端口，对外域名为你自己的域名：

server {
    listen 80;
    server_name 你的域名;
    location / {
        proxy_pass 后端地址;
        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;
    }
}

逐行理解它并不难：listen 80 表示 Nginx 在 80 端口接客；server_name 匹配请求的域名；location / 表示匹配所有路径；proxy_pass 是核心指令，负责把请求转发给后端，这里的后端地址在实际配置中写成后端服务的协议加地址加端口；后面的 proxy_set_header 则是把原始 Host、客户端真实 IP 和协议透传给后端，否则后端看到的可能只是代理地址，日志和鉴权都会失真。

写好配置后，先用 nginx -t 检查语法，再用 nginx -s reload 平滑重载，不要直接重启整个服务。改配置前备份原文件，是一个值得养成的好习惯。

四、把服务暴露到公网前的安全清单

反向代理本身不是万能护盾，配置不当反而会放大风险。上线前可以逐项自查：第一，只在入口开放必要的端口，通常是 80 和 443，应用端口、数据库端口和管理端口不要对外放行；第二，尽早启用 HTTPS，并把 80 端口的请求重定向到 443，避免账号和 Token 在明文里传输。

第三，限制请求体大小和超时时间，防止超大请求或者慢连接拖垮后端；第四，对登录、短信、搜索等敏感接口做限流，避免被暴力刷请求；第五，关闭或者严格保护管理路径，管理后台最好只允许特定来源访问，或者单独走一套认证；第六，开启访问日志和错误日志，出问题时才能定位是入口层、网络层还是后端的问题。

第七，定期更新 Nginx 和后端依赖，关注安全公告；第八，生产环境不要把详细的错误堆栈直接返回给客户端，统一返回友好的错误页面。把这些当成上线检查表，而不是出了问题再补，成本会低很多。

五、常见问题与排错思路

遇到 502 Bad Gateway，通常是 Nginx 找不到后端：先确认后端进程是否在运行、端口是否正确、监听地址是不是 127.0.0.1 还是 0.0.0.0，再看防火墙和安全组有没有放行内网通信。遇到 404，先区分是 Nginx 的 location 没匹配上，还是后端路由本身不存在，可以对照访问日志里的请求路径来判断。

如果页面能打开但样式错乱，往往是静态资源路径或者 Host 透传的问题；如果登录后频繁掉线，要检查 Cookie 的域名、路径和 Secure 属性在代理后是否还一致。排错时按“客户端、域名解析、Nginx、网络、后端”这个顺序逐段验证，比反复改配置更有效。

结语

反向代理的核心思想并不复杂：对外只暴露一个统一、安全、可控的入口，对内则保留灵活调整的空间。先从一个最简配置跑通，再逐步加上 HTTPS、限流、日志和负载均衡，就能把后端服务稳妥地带到公网。理解了这一层，很多部署和安全问题都会变得清晰得多。