芋道项目部署:前端写死后端地址 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

Python+微信API开发智能客服机器人:从接入到优化的全流程指南

最近在做一个智能客服项目,需要对接微信公众号,让用户能直接在微信里和机器人对话。过程中踩了不少坑,也积累了一些经验,今天就来聊聊怎么用 Python 和微信 API 一步步搭建一个稳定、高效的智能客服机器人。 1. 背景与常见痛点分析 刚开始做的时候,觉得不就是收消息、回消息嘛。但真跑起来,问题就来了: * 消息延迟与丢失:用户发了消息,后台处理慢了,或者微信服务器回调时网络波动,用户可能就收不到及时回复,体验很差。 * 会话状态管理混乱:客服对话是有上下文的。比如用户问“我的订单”,机器人得知道是哪个用户的哪个订单。用内存存状态,服务一重启就全丢了。 * API调用限制与频率控制:微信公众平台的接口有调用频率限制,比如获取 access_token,每天次数有限,而且所有业务共用。如果没管理好,频繁调用,很容易触发限流,导致整个服务不可用。 * 多租户与高并发:如果你的客服系统要服务多个公众号(多租户),消息路由、配置隔离就是个麻烦事。用户量一大,QPS上来,简单的同步处理根本扛不住。

By Ne0inhk

OpenClaw实战系列01:OpenClaw接入飞书机器人全接入指南 + Ollama本地大模型

文章目录 * 引言 * 第一步:环境准备与核心思想 * 第二步:部署Ollama——把大模型“养”在本地 * 1. 安装 Ollama * 2. 拉取并运行模型 * 3. 确认API可用性 * 第三步:安装OpenClaw——AI大脑的“躯干” * 1. 安装Node.js * 2. 一键安装 OpenClaw * 3. 验证安装 * 第四步:打通飞书——创建并配置机器人 * 1. 创建飞书应用 * 2. 配置机器人能力 * 3. 发布应用 * 第五步:OpenClaw与飞书“握手” * 方法一:使用 onboard 向导重新配置(推荐最新版) * 方法二:手动添加渠道 * 批准配对 * 第六步:实战测试与玩法拓展

By Ne0inhk
Flutter 三方库 wallet_connect 的鸿蒙化适配指南 - 实现 Web3 钱包协议连接、支持 DApp 授权登录与跨链交易签名实战

Flutter 三方库 wallet_connect 的鸿蒙化适配指南 - 实现 Web3 钱包协议连接、支持 DApp 授权登录与跨链交易签名实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 wallet_connect 的鸿蒙化适配指南 - 实现 Web3 钱包协议连接、支持 DApp 授权登录与跨链交易签名实战 前言 在进行 Flutter for OpenHarmony 的去中心化应用(DApp)或加密货币钱包开发时,支持标准的 WalletConnect 协议是链接用户钱包的关键。wallet_connect 是该协议的 Dart 实现,它能让你的鸿蒙 App 安全地与 MetaMask、Trust Wallet 等钱包建立双向加密连接。本文将探讨如何在鸿蒙系统下构建安全、稳定的 Web3 授权流程。 一、原理解析 / 概念介绍 1.1 基础原理

By Ne0inhk

OpenClaw 新手指南:从零开始的 AI 机器人搭建完全攻略

OpenClaw 新手指南:从零开始的 AI 机器人搭建完全攻略 想随时随地通过微信、飞书、Telegram 等平台与 AI 助手对话?OpenClaw 帮你实现。 为什么选择 OpenClaw? OpenClaw 是一个开源的自托管 AI 网关,让你可以在自己服务器上运行一个 central hub,连接所有聊天平台到强大的 AI 模型(如 Claude、GPT、Pi、Kimi 等)。 核心优势: * ✅ 数据完全掌控(自托管,隐私安全) * ✅ 多平台统一管理(一个网关服务所有渠道) * ✅ 无代码扩展(通过技能系统) * ✅ 24/7 可用(开机自启动) * ✅ 日志和记忆(支持长期对话) 10个核心技巧详解 技巧 1:快速安装与配置 适用场景:

By Ne0inhk