前后端分离源码上线Nginx反向代理配置实操及路由防错

做前后端分离的应该都有体会，把前端源码打个包丢上服务器，离真正能上线还差着一大截。真放到生产环境里跑，跨域报错、后端端口直接暴露这种感觉很不安全，这些破事都得靠Nginx在前面做一层反向代理来处理。周围运维同事经常吐槽，七成以上的上线故障跟代码逻辑压根没关系，都栽在代理路径怎么拼接、请求头有没有带过去这种细节上。有些人图省事，把前端的静态资源和后端API全都挂在同一个域名下面，表面上看访问路径干干净净，但其实这种挂法对转发规则的匹配要求更高，稍微写得不够严谨，各种奇奇怪怪的访问问题就冒出来了。

路由刷新与接口转发的处理门道

用Vue或者React搭的项目一旦开了history路由模式，在子页面刷新直接甩个404出来，这问题算是经典老坑了。解决方法其实不复杂，在Nginx的server块里加上try_files，告诉它如果请求找不到对应的静态文件，就自动回退到入口文件index.html，一般写一句try_files $uri $uri/ /index.html就够用。接口转发这块，proxy_pass后面带不带斜杠是个特别容易翻车的地方。末尾带了斜杠，Nginx会把location匹配到的路径前缀直接截掉，再把剩下的部分传给后端；没加斜杠的话，会把匹配到的完整路径原封不动地交给后端接口。要是后端用的Spring Boot或者Node.js，没有针对这两种情况做兼容，那404排着队就来了。转发的过程中顺手把Host、X-Real-IP这些请求头加上也挺重要，不然后端那边拿到的来源地址全是代理服务器的IP，日志里看不出真实用户的访问轨迹，排查问题会多绕很多弯路。

面对502报错的排查动线

碰上502网关报错，基本就是Nginx和后端服务之间通信断了。这个时候别一上来就乱改配置，先ssh到服务器上用netstat查一下后端服务的端口有没有在正常监听。好多开发在本地调试完直接把服务扔上去，图方便只绑了127.0.0.1回环地址，代理转发虽然大部分时候能通，可偶尔会被系统权限或者网络策略卡住。可以在装Nginx的这台服务器上直接用curl去请求后端的接口地址，要是curl能正常返回内容，但浏览器还是502，那多半是防火墙或者SELinux在中间拦了一下；要是curl都请求不通，就说明后端进程可能崩了，或者端口被别的程序占了。排查的时候可以把Nginx的错误日志级别临时改成debug，专盯Connection refused和upstream timed out这些关键词，故障点一般很快就能揪出来。每次改完配置，一定要先用nginx -t做一下语法校验，确认没写错再执行reload重载，千万别直接在线上边改边试，不然搞出更大麻烦真的会头疼。