你是否遇到过这样的问题？
- 你用 Nginx 将
https://api.dbblive.com代理到内网http://127.0.0.1:8080； - 正常访问时 URL 显示正常；
- 但一旦点击浏览器刷新（F5），地址栏突然变成
https://api.dbblive.com:8080/some/path； - 更糟的是，页面可能直接 404 或无法加载。
这不仅暴露了后端端口（安全风险），还破坏了用户体验。问题出在哪？如何彻底解决？
别急，本文将带你定位根源，并给出一劳永逸的 Nginx 配置方案。
一、问题根源：后端服务返回了带端口的重定向
问题通常不在 Nginx，而在后端应用！
当你的后端服务（如 Spring Boot、Go API、Node.js 等）收到请求时，它会根据Host和Port信息生成重定向（Redirect）或绝对 URL。例如：
- 请求：
GET /admin→ 后端返回302 Found，Location: http://api.dbblive.com:8080/login - 或前端 JavaScript 中拼接了
window.location.origin，而origin被识别为https://api.dbblive.com:8080
为什么会带:8080？
因为 Nginx 默认不会告诉后端“原始请求是通过 443 端口进来的”。后端看到的是http://127.0.0.1:8080，于是按自己的端口生成 URL。
二、解决方案：正确传递原始请求信息给后端
你需要在 Nginx 反向代理配置中显式设置关键 HTTP 头，让后端“以为”它直接处理了 443 端口的请求。
✅ 正确的 Nginx 配置如下：
server { listen 443 ssl http2; server_name api.dbblive.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; # 后端服务地址 # 关键：传递原始 Host 和协议信息 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; # 告诉后端是 HTTPS proxy_set_header X-Forwarded-Port $server_port; # 告诉后端原始端口是 443 # 可选：隐藏后端 Server 信息 proxy_hide_header X-Powered-By; } }🔑 核心配置项说明：
| 配置项 | 作用 |
|---|---|
proxy_set_header Host $host; | 最关键！让后端看到的是api.dbblive.com，而不是127.0.0.1:8080 |
proxy_set_header X-Forwarded-Proto $scheme; | 告诉后端原始请求是https（避免后端生成http://链接） |
proxy_set_header X-Forwarded-Port $server_port; | 明确告知原始端口是443（非必需，但推荐） |
💡
$server_port在listen 443时为443，确保后端不会误用8080。
三、后端应用需正确处理代理头
光配 Nginx 还不够！后端必须信任并使用这些代理头。
示例：Spring Boot
在application.yml中启用：
server:forward-headers-strategy:native# Spring Boot 2.2+# 或使用 tomcat:tomcat:remoteip:remote-ip-header:x-forwarded-forprotocol-header:x-forwarded-proto示例：Node.js（Express）
使用trust proxy：
app.set('trust proxy',true);// 此后 req.protocol 会是 'https'，req.get('host') 会是 'api.dbblive.com'示例：Go（Gin）
import"github.com/gin-gonic/contrib/sessions"r:=gin.New()r.Use(gin.Recovery())r.Use(func(c*gin.Context){c.Request.Header.Set("X-Forwarded-Proto","https")c.Next()})✅原则：后端在生成重定向、拼接 URL 或判断协议时，优先使用
X-Forwarded-*头，而非直接读取本地端口。
四、验证是否修复成功
- 访问
https://api.dbblive.com/some/page - 按
F5刷新页面 - 观察地址栏：应始终为
https://api.dbblive.com/...，不出现:8080 - 检查网络面板（Network）：
- 所有 302 重定向的
Location头应为https://api.dbblive.com/... - 无
:8080出现
- 所有 302 重定向的
五、额外建议：避免前端拼接错误 URL
如果你的前端是 SPA（如 Vue/React），也要确保：
- 使用相对路径或配置
BASE_URL； - 避免硬编码
window.location.origin（在代理环境下可能不可靠）； - API 请求地址使用相对路径（如
/api/xxx），由 Nginx 统一代理。
六、总结
URL 刷新后暴露后端端口，本质是代理信息未正确透传+后端未正确处理代理头。解决只需两步：
- Nginx 配置：设置
Host、X-Forwarded-Proto、X-Forwarded-Port； - 后端适配：信任并使用这些头信息生成 URL。
这样，无论用户如何刷新、跳转，URL 始终干净、安全，且符合域名规范。
小提醒：在抖爸爸这类中大型互联网公司，统一接入层（如 Nginx）与后端服务的协议对齐是基础规范。确保团队所有服务都遵循
X-Forwarded-*标准，可避免大量“端口泄露”类问题。
附：快速检查命令
# 检查后端是否返回带端口的 Locationcurl-I https://api.dbblive.com/admin# 应返回：# Location: https://api.dbblive.com/login ✅# 而非：# Location: http://api.dbblive.com:8080/login ❌现在，你可以安心让用户刷新页面了！
