芋道项目部署:前端写死后端地址 vs Nginx 反向代理

两种方式的区别、风险与完整配置(小白也能照做)

很多同学第一次部署芋道(Ruoyi-Vue-Pro / 芋道源码)这种前后端分离项目,常见两种访问方式:

  1. 前端直接请求后端域名(把 API 地址写死成 https://api.xxx.com
  2. 前端只请求自身域名,Nginx 反向代理转发到后端(前端写 /api,Nginx 转发到 127.0.0.1:48081

这两种都能跑起来,但生产环境推荐的做法很明确:
Nginx 反向代理(同域转发)更稳、更安全、更省心

下面用 芋道项目为例,带你从 0 配置到可用,并解释常见坑(比如你遇到的:为什么页面里会看到 localhost)。


1. 两种方式是什么?(先把概念讲明白)

方式 A:前端写死后端域名(直连后端)

结构通常是:

  • 前端:https://www.example.com
  • 后端:https://api.example.com(或 http://IP:48081

前端代码里直接写死:

axios.defaults.baseURL ="https://api.example.com"

优点:

  • ✅ 配置简单,改个地址就能跑
  • ✅ 前端、后端可以独立部署到不同机器

缺点(生产更明显):

  • ❌ 需要配置 CORS(跨域),容易误配
  • ❌ 后端域名暴露在公网,攻击/扫描成本低
  • ❌ 统一限流、防刷、黑名单、WAF 不好做
  • ❌ Cookie/会话类场景容易踩坑(跨域 Cookie、SameSite)

方式 B:Nginx 反向代理(同域转发)

结构通常是:

  • 对外只暴露一个域名:https://www.example.com
  • 前端请求:https://www.example.com/api/...
  • Nginx 转发到:http://127.0.0.1:48081/...

前端代码只写相对路径:

axios.defaults.baseURL ="/api"

优点(生产推荐):

  • ✅ 前后端同域:不用 CORS,Cookie/登录态更稳
  • ✅ 后端真实地址不暴露(甚至可以只监听 127.0.0.1)
  • ✅ Nginx 层可以统一做限流、防刷、日志审计、黑名单
  • ✅ 更接近真实生产架构(尤其是 Java 项目)

缺点:

  • ❌ 初次配置比直连稍复杂(但一次配置长期收益)

2. 你问的关键点:为什么页面里会看到 localhost?

这是很多人第一次用 Nginx 转发时的误会:

Nginx 的 proxy_pass http://127.0.0.1:48081,浏览器是看不到的。
浏览器只会看到自己请求的域名,比如 https://www.example.com/api/...

那为什么你在 Network 或页面里看到 localhost

只有几种可能:

  1. 前端代码仍然写死了 http://localhost:48081(最常见)
  2. 后端返回的数据里包含了绝对 URL(例如文件下载、图片访问地址)
  3. 后端返回 302/重定向,Location Header 拼成了 localhost
  4. 你看到的是 开发环境(npm run dev)的代理配置(dev 下正常)

后面文章会专门讲如何修。


3. 方式 A:前端写死后端地址(直连后端)怎么配置?

3.1 后端(芋道)部署

后端通常是 Spring Boot Jar,监听一个端口,比如 48081:

server:port:48081

如果你要直连后端域名(例如 api.example.com),一般会:

  • 给后端配置一个域名和证书(HTTPS)
  • 或直接暴露 IP:48081(不推荐)

⚠️ 安全建议:如果要暴露后端到公网,至少要做到:

  • 配防火墙允许的 IP/网段(如只允许前端服务器访问)
  • 访问限流(Nginx/WAF/网关)
  • 严格鉴权、权限校验、日志审计

3.2 前端配置 baseURL(直连)

假设后端对外是:

  • https://api.example.com/admin-api

前端配置(以常见封装为例):

// 生产环境 axios.defaults.baseURL ="https://api.example.com"

如果你的后端 API 前缀是 /admin-api,那通常前端请求会是:

  • https://api.example.com/admin-api/xxx

3.3 CORS 必须处理(直连方式的核心)

因为前端域名和后端域名不同(跨域),必须配置 CORS,否则浏览器直接拦。

典型错误:为了省事把 allowedOrigins=* 全放开
这在生产很危险。

更合理的做法是:
只允许你的前端域名:

  • https://www.example.com

(具体芋道版本/模块 CORS 配置位置可能不同,但原则一致:*别写成 ,别乱放开


4. 方式 B:Nginx 反向代理(同域转发)怎么配置?

这才是本篇文章的重点:芋道生产推荐方案

4.1 后端只监听本机(强烈推荐)

让后端对外“不可见”,只给 Nginx 转发即可:

server:port:48081address: 127.0.0.1 # ★关键:仅本机可访问

并且防火墙不要放行 48081。

这样做的效果是:
✅ 外面扫描不到你的 Java 端口
✅ 只有 Nginx(同机)能访问后端


4.2 前端配置(只用相对路径)

前端不要再写后端域名,改成:

axios.defaults.baseURL ="/api"

重新打包:

npm run build 

dist 放到你的站点目录,比如:

/www/wwwroot/yudao-front/dist


4.3 Nginx 站点配置(宝塔可直接粘贴)

宝塔里:网站 → 设置 → 配置文件
写成类似下面(按你的实际域名、目录改一下):

server { listen 80; server_name www.example.com; # 前端静态资源 location / { root /www/wwwroot/yudao-front/dist; index index.html; try_files $uri $uri/ /index.html; } # 后端接口代理:把 /api/ 转到本机的 48081 location /api/ { proxy_pass http://127.0.0.1:48081/; 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,通了以后再在宝塔里一键申请证书,然后把 80 升级到 443。

4.4 路径对齐:芋道常见 API 前缀怎么处理?

芋道经常有:

  • /admin-api(管理端)
  • /app-api(APP)
  • /mp-api(公众号/小程序,视项目而定)

你有两种常见选择:

选择 1:前端走 /api,Nginx 直接转发到后端根路径(推荐)

前端请求 /api/admin-api/...
Nginx 转发到 http://127.0.0.1:48081/admin-api/...

对应 Nginx:

location /api/ { proxy_pass http://127.0.0.1:48081/; } 

这样 /api/ 会被去掉一层前缀,路径自然对齐。

选择 2:Nginx 做更细的拆分(更清晰)

比如:

location /admin-api/ { proxy_pass http://127.0.0.1:48081/admin-api/; } location /app-api/ { proxy_pass http://127.0.0.1:48081/app-api/; } 

前端就直接请求 /admin-api/app-api,不需要再包一层 /api

两种都可以,推荐第 1 种(前端统一 /api,更利于后续加网关/限流)。


5. 常见坑:为什么出现 “localhost”?

5.1 如果 Network 里 Request URL 显示 localhost

说明:前端 baseURL 还是 localhost
检查是否有环境变量配置,例如:

  • .env.production
  • config.js
  • request.js

确保生产环境只用:

baseURL:"/api"

5.2 如果 Response Body 里出现 localhost

说明:后端返回了拼好的绝对地址,常见于:

  • 上传文件返回访问 URL
  • 导出下载地址
  • 回调地址

解决思路:

  • 后端不要硬编码 localhost
  • 用配置项注入“外部访问域名”
  • 或返回相对路径,由前端拼成当前域名

5.3 如果是 302/跳转 Location 里出现 localhost

一般是 反向代理 header 没带全 或 Spring 没识别 forward headers。

Nginx 必带:

proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

Spring Boot 建议开启:

server:forward-headers-strategy: native 

6. 两种方式到底怎么选?(最终推荐)

✅ 如果你是 Java 开发、部署芋道项目(你这种情况)

并且你说:不部署 PHP,只部署 Java 服务
那我的最终推荐非常明确:

生产环境优先选择:Nginx 反向代理(同域转发)

理由:更安全、无跨域、登录态更稳、运维能力更强

什么时候可以用“直连后端”?

  • 内部系统 / 内网访问
  • 测试环境
  • 前后端分开部署,且你有网关/WAF/限流能力

否则生产不建议。


7. 一个可直接照抄的“芋道 + 宝塔”部署清单

✅ 后端

  • server.port=48081
  • server.address=127.0.0.1
  • 防火墙不开放 48081

✅ 前端

  • baseURL="/api"
  • npm run build
  • dist 上传到宝塔站点目录

✅ Nginx(宝塔站点配置)

  • / → 前端静态资源
  • /api/proxy_pass http://127.0.0.1:48081/
  • 加全 proxy headers

✅ 验证

  • 浏览器 Network:Request URL 只出现 www.example.com/api/...
  • 不出现 localhost
  • 直接访问 IP:48081(公网)访问不到

8. 结语

部署这一步,很多人追求“先能跑起来”,然后在生产上留下隐患。
你现在主动从“直连后端”升级到“同域反向代理”,其实就是在做正确的工程化

Read more

JAVA 动态代理:从原理剖析到实战应用

JAVA 动态代理:从原理剖析到实战应用

JAVA 动态代理:从原理剖析到实战应用 1.1 本章学习目标与重点 💡 掌握动态代理的核心概念与分类,理解动态代理在 Java 开发中的核心价值。 💡 熟练掌握 JDK 动态代理的实现流程与核心 API,能够独立编写 JDK 动态代理代码。 💡 了解 CGLIB 动态代理的实现原理与适用场景,对比 JDK 动态代理与 CGLIB 动态代理的差异。 💡 结合实际业务场景,掌握动态代理在 AOP 编程、权限控制、日志记录等场景中的实战应用。 ⚠️ 本章重点是 JDK 动态代理的核心实现 和 动态代理在 AOP 中的实战应用,这是 Java 高级开发与框架设计的必备技能。 1.2 动态代理的核心概念与价值 1.2.1 什么是动态代理 💡 动态代理 是

By Ne0inhk
Flutter 三方库 js_wrapping 的鸿蒙化适配指南 - 实现 Dart 与 JavaScript 的无缝对象包装、支持强类型回调与属性映射

Flutter 三方库 js_wrapping 的鸿蒙化适配指南 - 实现 Dart 与 JavaScript 的无缝对象包装、支持强类型回调与属性映射

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 js_wrapping 的鸿蒙化适配指南 - 实现 Dart 与 JavaScript 的无缝对象包装、支持强类型回调与属性映射 前言 在进行 Flutter for OpenHarmony 的 Web 混合开发时,频繁地在 Dart 层与底层 JavaScript 环境进行数据交互是不可避免的。虽然官方提供了基本的 dart:js,但在处理复杂的 JS 对象和回调时,代码往往会变得杂乱无章。js_wrapping 提供了一个更优雅的、类型安全的包装层。本文将指导大家如何在鸿蒙端利用该库提升 JS 互操作的开发体验。 一、原理解析 / 概念介绍 1.1 基础原理

By Ne0inhk

我和 AI 聊了一晚上,第二天它说“你好,请问有什么可以帮你?“凌晨我的 AI 尽然悄悄把记忆清空了!——OpenClaw Session 完全生存指南:重置、压缩、剪枝、记忆一网打尽

凌晨4点,我的 AI 悄悄把记忆清空了——OpenClaw Session 避坑指南 摘要:用 OpenClaw 搭了个 AI 助手,聊得好的,第二天一早它就"失忆"了?本文从一个真实踩坑出发,系统拆解 OpenClaw 的 Session 机制——重置(Reset)、压缩(Compaction)、剪枝(Pruning)、记忆(Memory)、会话控制(Session Tool)——帮你彻底搞懂"对话为什么会消失"以及"怎么让 AI 记住你"。 🤯 踩坑现场 事情是这样的: 我用 OpenClaw

By Ne0inhk

AI代码安全新纪元:Claude Code Security深度解析与实战指南

📋 摘要 2026年2月,Anthropic正式推出Claude Code Security——一款基于Claude Opus 4.6大模型的AI原生代码安全解决方案。这不仅是AI辅助编程领域的一次重大升级,更是向传统网络安全行业投下的“重磅炸弹”。本文将从技术原理、核心功能、实战应用、行业影响四个维度,深度解析这款颠覆性工具如何重新定义代码安全检测标准。我们将探讨其如何通过深度语义理解突破传统规则匹配的局限,如何实现“扫描-验证-修复”全流程自动化,以及它对企业安全实践带来的深刻变革。无论你是开发者、安全工程师还是技术决策者,本文都将为你提供全面、专业、可操作的指导。 🔑 关键字 AI代码安全、Claude Code Security、静态应用安全测试、漏洞扫描、智能补丁生成、DevSecOps 🌅 引言:传统安全工具的黄昏与AI黎明的曙光 在AI辅助编程导致代码生成速度成倍增长的今天,传统代码安全工具正面临前所未有的结构性矛盾。据统计,2024年全球报告的CVE(公共漏洞和暴露)数量已超过40,000个,且这个数字还在加速增长。然而,传统安全工具要么只能做浅层的

By Ne0inhk