Nginx 通过 location 精准匹配实现 SSR 代理：先声明 /api/、/static/ 等前缀路径，再用正则拦截静态资源，最后用 location / 代理动态路由至 Node.js SSR 服务，并传递真实客户端头信息。
在 Nginx 中通过 location 实现前后端同构应用的 SSR 渲染代理，核心是把浏览器对 HTML 页面的首次请求（如 /、/user/123）转发给 Node.js 服务做服务端渲染，而将静态资源（JS/CSS/图片等）和 API 请求直接由 Nginx 处理或透传，避免 SSR 服务成为性能瓶颈。
区分 SSR 页面请求与静态资源
关键在于用精准的 location 匹配规则识别“需要 SSR 的路径”。通常这些路径不带文件扩展名，且不以 /static、/api、/assets 等为前缀。
- 用正则
location ^~ /或location /捕获所有根路径请求，但需配合location ~* \.(js|css|png|jpg|gif|ico|svg|woff2?)$提前拦截静态资源，确保它们不落入 SSR 代理逻辑 - 推荐使用
location /+try_files组合：先查本地静态文件（如index.html），不存在再交给 SSR 服务；适用于部分预渲染页面 + 动态路由混合场景
配置 SSR 后端代理（如 Node.js Express/Nest/Nuxt）
将匹配到的动态路由（如 /blog/:id、/dashboard）反向代理到运行 SSR 的 Node 进程。注意传递真实客户端信息，确保 SSR 上下文准确。
- 设置
proxy_pass http://127.0.0.1:3000;（假设 SSR 服务监听 3000 端口） - 必须添加：
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; - 启用缓存可选：对 SSR 结果加
proxy_cache，但需谨慎处理 Cookie、Authorization 等敏感头，默认跳过缓存更安全
避免 SSR 代理覆盖 API 或静态资源路径
如果前端构建产物中 API 前缀为 /api，静态资源放在 /static，必须在 SSR 的 location / 之前显式声明这些路径，否则会被误代理。
location ^~ /api/ { proxy_pass http://backend-api; }location ^~ /static/ { alias /var/www/myapp/dist/static/; }location ^~ /assets/ { alias /var/www/myapp/dist/assets/; }- 注意：
^~优先级高于正则，能确保这些路径不被后续的location /拦截
处理 SPA 回退与 SEO 友好路由
同构应用常使用前端路由（如 React Router、Vue Router history 模式），需让 Nginx 对所有非资源请求都 fallback 到 SSR 服务，同时保证搜索引擎爬虫能获取真实 HTML。
- 不要用
try_files $uri $uri/ /index.html;（这是纯前端 SPA 方案），它会绕过 SSR，返回静态index.html而非服务端渲染内容 - 正确做法：对所有未命中静态文件或明确路径的请求，统一
proxy_pass到 SSR 服务，由其内部路由决定是否渲染 - 可在 SSR 服务中判断
User-Agent或isBot标识，对爬虫做轻量级 SSR，提升 SEO 效率
不复杂但容易忽略：Nginx 配置加载顺序影响极大，location 块务必按“精确匹配 → 前缀匹配（^~）→ 正则匹配 → 通用匹配（/）”从上到下书写，否则 SSR 代理可能意外捕获本该直出的资源。
