SSR服务器地址的标准写法是“协议 + 主机 + 端口 + 路径前缀”四段拼接，https://ssr.example.com:443/render；本地开发则写 http://127.0.0.1:3000。 只要这四段没有拼错、内网与外网地址没有混用,前端页面和服务端渲染之间的链路基本一次就能通。
SSR服务器地址到底由哪几部分组成
很多人卡在配置上，是因为把“地址”当成一个整体字符串去记，它其实是结构化数据,拆开看就清楚多了。
协议头：http 还是 https 不能随手写
服务端渲染进程通常跑在内网，前面挂一层反向代理对外提供服务，此时渲染进程自身监听的是 http，但对外暴露的地址必须写 https。
- 浏览器侧请求地址：
https://ssr.example.com - 服务内部回源地址：
http://127.0.0.1:3000 - 两者不能互相替代
如果页面里混用了 http 的 SSR 地址，浏览器会判定为混合内容并直接阻断请求，控制台出现 Mixed Content 报错，业内专家指出，服务端渲染场景下的跨协议请求错误,多数来自环境变量没有按环境区分。
主机段：内网IP、公网IP、域名三种写法各有用途
| 写法 | 典型值 | 适用场景 | 注意点 |
|---|---|---|---|
| 内网 IP | 0.3.27 | 同 VPC 内的渲染服务互调 | 跨机房不可达 |
| 公网 IP | 98.x.x | 临时联调 | 换 IP 就要改配置 |
| 域名 | ssr.example.com | 生产环境 | 需提前解析并配置证书 |
生产环境建议一律用域名，IP 写死之后，弹性扩容、更换机器都得重新发版。
端口与路径前缀：最容易漏的两段
默认端口 80 和 443 可以省略，非默认端口必须显式写出，https://ssr.example.com:8443，路径前缀则是当 SSR 服务挂在子路径下时才需要，https://example.com/store-ssr/，这时 Next.js 的 basePath 和 Nginx 的 location 都要同步改成 store-ssr，只改一边必然 404。
Next.js服务端渲染服务器地址配置方法
Next.js 项目的地址配置分散在三个位置,漏掉任何一处都会出问题。
环境变量文件的写法
在项目根目录建 .env.production：
# 对外访问的SSR地址，会被打进客户端bundle NEXT_PUBLIC_SSR_ORIGIN=https://ssr.example.com # 服务端内部回源地址，不会暴露给浏览器 SSR_INTERNAL_ORIGIN=http://127.0.0.1:3000
命名规则要记住：以 NEXT_PUBLIC_ 开头的变量会被内联到客户端代码里，只能放对外可见的地址；带鉴权信息或内网 IP 的地址放进不带前缀的变量,仅在服务端读取。
代码中的读取与兜底
const ssrOrigin = process.env.NEXT_PUBLIC_SSR_ORIGIN || (process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : '');
给出兜底值是为了避免变量缺失时拼出 undefined/api 这种无效地址，构建期注入的变量在运行时无法修改,所以容器化部署时要把它当成构建参数处理。
容器部署时的地址注入
Docker 打包 Next.js 时，NEXT_PUBLIC_ 变量在 next build 阶段就已固化，行业共识认为，服务端渲染容器应当把构建与运行拆成两个阶段，运行时地址通过环境变量传入，构建期地址通过 --build-arg 传入,否则同一镜像无法在测试环境和生产环境复用。
Nginx反向代理SSR服务器地址如何配置
反向代理这一层决定了外部访问地址与内部渲染地址如何对应。
upstream 指向内网地址
upstream ssr_node {
server 127.0.0.1:3000;
keepalive 32;
}
server {
listen 443 ssl http2;
server_name ssr.example.com;
location / {
proxy_pass http://ssr_node;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 60s;
}
}
proxy_set_header Host $host 这一行不能少，渲染框架常依据 Host 头生成页面内的绝对地址，缺了它会出现静态资源指向 0.0.1 的问题。
超时参数按渲染耗时调整
服务端渲染首屏需要等接口数据返回，默认 60 秒超时基本够用，若页面内有多个串行请求，proxy_read_timeout 可放宽到 90 秒，同时把 Node 服务侧的 server.timeout 一并调整，避免前端还在等、后端已断连。
协议转发决定回调地址是否正确
X-Forwarded-Proto 会告诉渲染服务“用户实际用的是 https”，第三方登录回调、支付跳转地址都依赖这个头进行拼接，缺失就会把用户带到 http 页面并丢失会话。
本地SSR地址和线上域名的区别
本地调试与线上部署的地址写法差异,是新手踩坑最集中的地方。
| 对比项 | 本地开发地址 | 线上部署地址 |
|---|---|---|
| 主机 | localhost / 127.0.0.1 | 备案域名 |
| 协议 | http | https |
| 端口 | 3000、8080 等非默认 | 443，通常省略 |
| CORS | 需要手动放行 | 同域可省略 |
| 证书 | 不需要 | 必须有效且未过期 |
本地如果要模拟线上环境，可以修改 hosts 文件把域名指向 0.0.1，再配合自签证书，这样地址写法就与线上完全一致，能提前暴露路径前缀、Cookie 域等问题。
内网环境下SSR服务器地址怎么填
内网或私有化部署时,地址填写要遵循两个原则。
- 前端请求地址与后端回源地址分开配置：浏览器拿到的是内网域名或网关地址，渲染进程回源用
0.0.1或容器服务名。 - 容器间通信优先用服务名：Kubernetes 环境下写
http://ssr-service:3000，比写 Pod IP 稳定得多，Pod 重建后地址也不会失效。
需要跨网段访问时，检查安全组是否放行了对应端口，多数“地址写得没错却连不上”的情况,问题都出在防火墙规则而非配置本身。
地址填写后仍报错的排查顺序
按下面顺序走一遍,绝大多数问题能定位：
- 用
curl -I http://127.0.0.1:3000确认渲染服务本身存活 - 用
curl -I https://ssr.example.com确认反向代理链路通 - 浏览器开发者工具看请求 URL 是否拼出了双斜杠 或多出
undefined - 检查环境变量是否在构建期注入，
printenv | grep SSR验证 - 检查证书链是否完整，链不全时部分客户端会静默失败
配置类问题九成出在地址拼接，而不是网络本身，据统计，前端团队排查 SSR 部署故障时，地址拼写与协议不一致占比较高，先把字符串打印出来看一眼,往往比翻日志更快。
关于SSR服务器地址配置的常见问答
SSR服务器地址可以写成相对路径吗？
可以，但要分场景，浏览器端的接口请求可以写 /api/render 相对路径，由当前域名自动补全，天然规避跨域，服务端渲染进程发起的请求不行，Node 环境没有 location 对象，必须写完整地址，否则会抛出 Invalid URL 错误,同一个项目里两种写法并存是正常的。
同一个地址在开发和线上表现不一致，问题出在哪？
优先查构建期注入的变量，带公开前缀的地址在 npm run build 时就写死进了产物，改动环境变量文件后不重新构建不会生效，其次是查 Cookie 的 Domain 属性，线上域名变更后旧 Cookie 不匹配,会导致渲染出的页面处于未登录状态。
SSR服务器地址变更后需要重启哪些服务？
需要三处同步：渲染进程的环境变量、反向代理的 upstream 配置、CDN 或网关的回源地址，改完后 nginx -t 校验语法再 nginx -s reload 平滑生效，渲染进程按部署方式滚动重启，只改其中一处，会出现部分请求仍然打到旧地址的情况,表现为错误率间歇性上升。
把地址拆成协议、主机、端口、路径四段，分别确认外部可访问性和内部回源路径，SSR 的地址配置就不再是靠试错解决的事情。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794560.html
