后端服务跑起来了，外面却访问不到？Nginx 反向代理一次讲清

做后端开发，迟早会遇到这样一个时刻：服务在服务器上明明跑起来了，curl localhost:3000 也有响应，可从浏览器里打开公网地址，却只看到一片空白或者连接超时。我第一次遇到时，第一反应是服务挂了，重启了三遍都没用。后来才发现，问题根本不在服务本身，而是缺了一个“门面”：Nginx 反向代理。这篇就把这个最常见的部署环节讲清楚。

反向代理到底是干什么的

先说一个类比。你的后端服务像一家开在巷子深处的小店，知道门牌号（IP + 端口）的人才能找到它。Nginx 反向代理就是在巷子口立了个招牌加前台：所有客人都先到前台，前台再把人领到对应的店里。

具体到技术上，它做三件事：第一，统一入口。80 端口只留给 Nginx，外部永远只访问 80 或 443；第二，转发请求。Nginx 按规则把请求转给身后不同端口的服务；第三，顺手干杂活。静态文件、HTTPS 证书、限流，都可以在这一层解决，服务本身只管业务逻辑。

最小可用配置，五分钟跑起来

假设你的 Node 服务跑在 3000 端口。装好 Nginx 后，新建一个配置文件，核心就这几行：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

proxy_pass 是转发的目标，proxy_set_header 这两行别省：不传 Host，后端拿到的域名是错的；不传 X-Real-IP，后端日志里所有访问者的 IP 都会变成 127.0.0.1，出问题根本没法定位。我第一次配的时候就漏了第二行，查了半天日志才发现所有请求都长一个样。

写完配置别急着重启，先跑 nginx -t 检查语法，通过了再 nginx -s reload 平滑重载。直接重启 Nginx 会断掉正在处理的连接，重载不会，这是个好习惯。

一个端口跑多个服务

一台服务器上往往不止一个服务：API 跑 3000，前端跑 3001，管理后台跑 3002。反向代理的价值这时就体现出来了：按路径分流。

location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

location / {
    proxy_pass http://127.0.0.1:3001;
}

访问 example.com/api/users 走 API 服务，访问 example.com/ 走前端，浏览器只看到一个域名。注意一个细节：location /api/ 后面的斜杠和 proxy_pass 后面有没有 URI，会影响转发的路径拼接，配完一定要用 curl 实测一次，别凭感觉。

出问题先查这三处

反向代理配完访问不通，别慌，按这个顺序查，九成问题都在里面：

第一，看 Nginx 日志。/var/log/nginx/error.log 会直接告诉你转发失败的原因，是连接被拒绝还是超时，比猜快得多。

第二，看安全组和防火墙。服务在 3000 端口能跑，不代表 80 端口对外放行了。云服务器的安全组和服务器本机的防火墙是两道门，都要放行 80 和 443。

第三，看服务监听的地址。如果服务只监听了 127.0.0.1，本机 curl 能通，Nginx 转发也没问题；但如果服务监听的是某个内网地址，而 Nginx 配的是 127.0.0.1，转发就会失败。ss -tlnp 看一眼监听地址和端口，花不了十秒。

写在最后

反向代理不是什么高深技术，它就是后端部署里最基础的一块拼图：一个统一入口，一套转发规则，再加两行请求头。但正是这块拼图，决定了你的服务能不能被外面正常访问。第一次配的时候照着上面走一遍，配通一次，以后换什么语言、什么框架，思路都是一样的。