本文详解 Go 应用部署中 Nginx 静态资源托管与动态路由代理的协同配置，解决因 try_files 与 proxy_pass 混用导致的 CSS/JS/图片 404、前端路由失效等典型问题，并给出生产就绪的配置范式。
本文详解 go 应用部署中 nginx 静态资源托管与动态路由代理的协同配置，解决因 `try_files` 与 `proxy_pass` 混用导致的 css/js/图片 404、前端路由失效等典型问题，并给出生产就绪的配置范式。
在将 Go Web 应用（如基于 Gin、Echo 或标准 net/http 的服务）部署到 Ubuntu 服务器并接入 Nginx 时，一个高频陷阱是：所有静态资源（/css/app.css、/js/main.js、/images/logo.png）全部返回 404，仅 index.html 可访问，且前端路由（如 /dashboard）也报错。这并非 Go 代码问题，而是 Nginx 配置逻辑冲突所致——您当前配置中将 try_files 和 proxy_pass 同置于 location / 块内，导致 Nginx 在尝试代理前已强制匹配本地文件系统路径，而 Go 应用的模板（如 index.gohtml）并未实际存放于 /var/www/html/ 下，造成资源“既找不到，又没转发”。
✅ 正确解法：分离静态与动态请求路径
Nginx 的核心原则是 “先静态，后代理”。应显式区分两类请求：
- 若请求的 URI 对应真实存在的静态文件（如
/css/style.css），直接由 Nginx 返回，不经过 Go； - 若文件不存在（如
/api/users或单页应用 SPA 的/settings），再交由 Go 后端处理。
推荐采用命名 location（@proxy）实现无歧义分流：
server {
listen 80;
server_name example.com;
# 静态资源根目录（注意：指向存放 dist/public 的父级）
root /var/www/myapp; # ✅ 不是 /var/www/html，需与 Go 项目结构对齐
# 优先尝试匹配静态文件或目录
location / {
try_files $uri $uri/ @proxy;
}
# 所有未命中静态资源的请求，交由 Go 服务处理
location @proxy {
proxy_http_version 1.1;
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;
proxy_pass http://127.0.0.1:8001/; # ⚠️ 末尾斜杠至关重要！
}
# 【可选但强烈推荐】专用于静态资源的精细化控制
location ~ ^/(css|js|images|fonts|favicon\.ico|assets)/ {
expires 1h;
add_header Cache-Control "public, immutable";
# root 自动拼接：请求 /js/app.js → 查找 /var/www/myapp/js/app.js
}
}? 关键说明：
root /var/www/myapp表示 Nginx 将以该路径为基准拼接$uri。若您的 Go 项目构建产物（如dist/）位于/var/www/myapp/dist，则应设root /var/www/myapp/dist；若dist内文件直接放在/var/www/myapp/下，则保持当前设置。proxy_pass http://127.0.0.1:8001/末尾的/是硬性要求：它确保location /api/请求被重写为http://127.0.0.1:8001/api/xxx，而非错误地拼接成http://127.0.0.1:8001/api/xxx（无/时会丢弃location路径前缀）。@proxy是内部命名 location，仅用于try_files的 fallback，不响应外部直接请求，安全且高效。
⚠️ Go 服务端必须配合调整
Nginx 代理后，Go 代码不能再依赖原始请求字段：
- ❌ 错误：
r.RemoteAddr→ 返回127.0.0.1:54321（Nginx 连接地址） - ✅ 正确：
r.Header.Get("X-Forwarded-For")→ 获取真实客户端 IP（需 Nginx 设置X-Real-IP或X-Forwarded-For） - ❌ 错误：
r.URL.Scheme→ 恒为"http"（即使 HTTPS 访问） - ✅ 正确：
r.Header.Get("X-Forwarded-Proto") == "https"→ 判断是否经由 HTTPS 进入
示例中间件（适用于任何框架）：
func ProxyHeaders(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// 修复 Host（避免生成 http://localhost:8001/ 链接）
if host := r.Header.Get("Host"); host != "" {
r.Host = host
}
// 修复 Scheme
if proto := r.Header.Get("X-Forwarded-Proto"); proto == "https" {
r.URL.Scheme = "https"
}
next.ServeHTTP(w, r)
})
}
// 使用：http.ListenAndServe("127.0.0.1:8001", ProxyHeaders(handler))? 常见错误清单（避坑指南）
| 问题现象 | 根本原因 | 修复方式 |
|---|---|---|
GET /js/app.js 404 |
root 路径错误，或静态文件未上传至对应目录 |
ls -l /var/www/myapp/js/ 确认文件存在；检查 root 是否指向父目录 |
Location 重定向跳转到 http://localhost:8001/
|
Go 代码用 r.Host 生成绝对 URL，未适配代理 |
使用上述中间件覆盖 r.Host 和 r.URL.Scheme
|
| WebSocket 连接 60s 后断开 | Nginx 未透传 Upgrade/Connection 头 |
在 @proxy 块中添加 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
|
Go 服务监听 0.0.0.0:8001
|
允许外部直连，绕过 Nginx 安全层 | 改为 127.0.0.1:8001，执行 ss -tln \| grep :8001 验证 |
最后，重启服务并验证：
sudo nginx -t && sudo systemctl reload nginx curl -I http://example.com/css/style.css # 应返回 200 curl -I http://example.com/api/health # 应返回 Go 服务响应
遵循此配置，您将获得：Nginx 高效托管静态资源、Go 专注业务逻辑、前后端完全解耦、HTTPS 终止统一管理——这才是生产环境 Go Web 应用的标准部署形态。
