Nginx代理剥离路径前缀与Node.js自行处理的优劣势对比

两种方案我在生产环境都落地过，没有绝对的优劣，完全看团队和业务场景适配，各自的优缺点整理如下：

优点 #

• 后端业务代码完全不需要感知公共前缀的存在，Node.js侧的路由可以直接按/app-prefix/controller-prefix/resource编写，后续不管是升级API版本到v2、还是临时调整公共路径前缀，只需要修改Nginx配置执行reload即可，不用改动后端代码、不需要重启Node服务。
• 多服务、多版本路由调度灵活性极高，后续要新增/api/v2指向新部署的服务、或者把/api/v1/pay这类特殊路径单独转发到独立的支付服务，直接在Nginx层加规则就能实现，后端各服务之间不会出现路由冲突。
• 天然适配本地开发场景，本地启动Node服务调试时，直接访问根路径下的路由就能调通接口，不需要额外给本地环境配置前缀兼容逻辑，能减少开发、生产环境配置差异带来的踩坑。

缺点 #

• Nginx配置有额外维护成本，rewrite规则必须写得足够严谨——如果正则漏匹配、忘了透传query参数、重写时多吞/多拼了路径段，很容易导致全量接口404，排障时需要同时核对Nginx和Node两边的日志，排查链路比直连模式长。
• Node侧拿到的请求路径和用户实际访问的路径不一致，如果业务需要做全路径日志埋点、拼接接口回调地址、生成分页的next链接，必须让Nginx把被剥离的前缀通过X-Forwarded-Prefix这类自定义头传给后端，漏配就会生成错误的访问地址。
• 写得粗糙的重写正则可能带来安全风险，比如匹配规则过于宽松，可能把非预期的路径转发到后端，引发越权访问问题。

优点 #

• 代理链路非常简单，Nginx只需要配置最基础的反向代理规则，不需要写复杂的rewrite逻辑，配置出错概率极低，排障时Nginx日志记录的请求路径和Node侧收到的路径完全一致，查问题效率很高。
• 应用对请求路径有完整控制权，Node侧可以直接拿到用户访问的完整原始路径，做签名校验、日志埋点、回调地址拼接时不需要依赖代理传递的额外请求头，不会出现前缀丢失的问题。
• API版本逻辑完全内聚在应用内部，如果不同版本的接口存在逻辑差异（比如v1和v2同个接口的鉴权逻辑、返回结构不一样），直接在Node的路由层按前缀划分版本即可，不用跨Nginx和应用两端改配置。

缺点 #

• 后端代码和公共前缀强耦合，所有路由都要挂载在/api/v1前缀下，后续如果要调整公共前缀、或者把服务部署到其他不带这个前缀的网关后面，必须修改应用路由配置、重新发布服务。
• 本地开发需要额外做前缀兼容，要么本地调试时所有接口都手动带上/api/v1前缀，要么用本地开发代理（比如Vite Proxy、Webpack DevServer）先做一层前缀剥离，多了一层本地配置，很容易出现开发环境和生产环境路径不一致的问题。
• 后续做服务拆分的灵活度差，如果要把部分模块从当前Node服务拆出去单独部署，必须同时修改Nginx的转发规则和Node侧的路由挂载逻辑，两端同步调整很容易漏改，引发接口故障。

选型参考：如果业务迭代快、未来大概率有多版本API共存、或者有微服务拆分计划，优先选方案一；如果是小团队维护的单体服务、长期不会做架构调整、想降低配置复杂度，选方案二更省心。

内容的提问来源于stack exchange，提问作者noamtm