有一次我和后端联调对方在企业微信里问你那个请求到底打到哪个环境了我打开浏览器开发者工具看到 Request URL 一栏稳稳写着 http://localhost:8080/api/user/info第一反应是回复他“就这个啊”结果字打了一半自己先愣住了——开发服务器上的地址怎么可能是后端真正收到请求的地址呢。这其实就是 Vue 项目里配置了请求代理之后最常见的困惑浏览器 Network 面板里显示的地址和服务器实际接收请求的地址中间隔了一层 Node 进程而这个转发过程在默认情况下对前端开发者几乎是透明的。这篇就来把“配置了 vue 请求代理之后如何查看真实请求地址”这件事彻底讲清楚包括原理、可复现的实操方法、常见的坑以及我平时在项目里惯用的调试习惯。1. 先弄明白“浏览器地址”和“真实地址”差在哪1.1 代理到底解决了什么问题前后端分离开发的时候前端跑在 8080 或 5173后端跑在 8081、7001 之类的端口两边一访问就撞上浏览器的同源策略。同源策略是浏览器层面的安全机制它规定页面里的异步请求只能访问同协议、同域名、同端口的资源。前端是 localhost:8080后端是 localhost:8081端口不一样浏览器直接就把跨域请求拦了。要绕开这个限制常见方案有 JSONP、后端开 CORS、Nginx 转发还有开发环境里的 devServer 代理。其中 devServer 代理是最省事的一种因为它在“开发服务器”这一层做转发前端代码不需要改后端也不用额外处理跨域头。你可以把它理解成前台代收快递你寄东西的时候只写了前台的地址前台收到之后再帮你转给真正的收件人。浏览器里看到的永远是“前台”的地址而快递最终送到谁手里浏览器一无所知。1.2 代理转发链路拆解一个配置了代理的 Vue 项目请求链路由三段组成浏览器向开发服务器发起请求比如 http://localhost:8080/api/user/info开发服务器webpack-dev-server 或 vite dev server接收到请求后根据 proxy 配置把这个请求原样或经过改写后转发给 target 指定的后端地址后端处理完响应原路返回后端 - 开发服务器 - 浏览器这里最容易被忽略的是浏览器只参与了第 1 步和第 3 步的“看得到的部分”。第 2 步是在 Node 进程内部完成的浏览器开发者工具里看不到Network 面板永远只显示你访问开发服务器的那个地址。所以当后端跟你说“我没收到这个请求”或者“我收到的是另一个地址”你不能拿浏览器里的 localhost 地址去对线。你需要的是“第二跳”的真实地址。1.3 为什么你之前用过的方法都不太准有些同学会去 axios 拦截器里打印 baseURL 和 url比如 console.log(config.baseURL config.url)。但这里打印的只是前端代码拼接出来的请求地址它描述的是“浏览器会向哪个地址发请求”而不是“代理最终转发到了哪里”。还有人习惯在浏览器 Network 面板里右键 Copy as cURL拿到之后一看也是 localhost 开头。它只是把第一跳请求转成了 cURL 命令代理转发的那一跳依然藏在黑盒里。也有同学会去看后端日志里的 IP结果发现后端拿到的来源 IP 是 127.0.0.1 或者开发服务器的局域网 IP这并不能直接告诉你真实地址。真正想看地址得在转发发生的节点上做文章。2. 几个真正能看到真实地址的方法2.1 手把手在代理配置里打印转发日志这是前端开发者自己就能做、又最直接的一种方式。原理很简单既然转发发生在 devServer 里那我就在转发的同时把目标地址打到终端里。先看 Vue CLIwebpack项目的 vue.config.js 写法module.exports { devServer: { proxy: { /api: { target: http://192.168.1.10:8081, changeOrigin: true, pathRewrite: { ^/api: }, onProxyReq(proxyReq, req) { const realUrl http://${proxyReq.getHeader(host)}${proxyReq.path} // 挂到 req 上后面 onProxyRes 里还能用 req._realUrl realUrl console.log([proxy], req.method, req.url, -, realUrl) }, onProxyRes(proxyRes, req, res) { // 响应头里把真实地址带给浏览器前端在 Network 里一眼就能看到 if (req._realUrl) { res.setHeader(X-Proxy-Real-Url, req._realUrl) } } } } } }关键点在 onProxyReq 这个回调它在 devServer 向后端发起转发请求之前执行。proxyReq 是真正要发给后端的请求对象proxyReq.getHeader(host) 这时候已经被替换成 target 的 host因为 changeOrigin 开启proxyReq.path 是经过 pathRewrite 处理之后的最终路径。把这些拼起来就是后端实际看到的地址。再说 Vite 项目。Vite 的 server.proxy 底层也是 http-proxy所以思路一模一样配置在 vite.config.ts 里import { defineConfig, loadEnv } from vite import vue from vitejs/plugin-vue export default defineConfig(({ mode }) { const env loadEnv(mode, process.cwd()) const target env.VITE_PROXY_TARGET || http://192.168.1.10:8081 return { plugins: [vue()], server: { proxy: { /api: { target, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ), configure(proxy) { proxy.on(proxyReq, (proxyReq, req) { const realUrl ${target}${proxyReq.path} console.log([vite-proxy], req.method, req.url, -, realUrl) proxyReq.setHeader(x-debug-real-url, realUrl) }) } } } } } })这里用 configure 钩子拿到 proxy 实例然后监听 proxyReq 事件。proxyReq.path 是重写之后的路径加上 target 就是真实地址。如果你在 rewrite 里把 /api 去掉了proxyReq.path 里就已经是去掉后的结果不需要手动再处理。注意改完配置文件一定要重启 devServerVite 对 server.proxy 的改动不一定会热更新我之前就在这里吃过亏改了没重启终端里一直没日志还以为代码写错了。2.2 在后端接口里回显完整 URL如果代理层不是你负责维护或者你压根不方便改 devServer 配置那就在后端接口里回显地址。这个方法适合调试阶段临时加一个调试接口或者直接在你正在调的接口里打个日志。Spring Boot 后端可以这样写RestController RequestMapping(/api) public class DebugController { GetMapping(/echo) public MapString, String echo(HttpServletRequest request) { MapString, String result new HashMap(); result.put(requestURL, request.getRequestURL().toString()); result.put(requestURI, request.getRequestURI()); result.put(host, request.getHeader(Host)); result.put(xForwardedFor, request.getHeader(X-Forwarded-For)); return result; } }前端请求 /api/echo后端把 requestURL、URI、Host 原样返回。这时候你在浏览器响应体里看到的就是后端视角里的“真实地址”。尤其 requestURL 里的 host 部分能直接看出请求是从哪个虚拟主机进来的。Node.js 的 Express 后端更简单app.get(/api/echo, (req, res) { res.json({ url: req.originalUrl, host: req.headers.host }) })这个方法有一个好处它验证的不只是路径对不对还包括请求头、host 等元信息。有些后端服务会根据 host 做路由或鉴权光看路径对不上号的情况也经常遇到。2.3 用抓包工具看第二跳如果不想在后端加代码也不想改前端配置那就用抓包工具。Charles、Fiddler、whistle 都能做。原理是让 devServer 发出的请求经过抓包工具的本地代理端口工具会把这一段流量记录下来。以 whistle 为例启动后在规则里配置http://localhost:8081 http://127.0.0.1:8080这句规则的意思是把所有流向 localhost:8081 的请求都导向 127.0.0.1:8080 的代理端口。然后你在 whistle 的 Network 面板里就能看到 devServer 转发给 target 的那一跳请求包含完整 URL、headers、响应状态。不过要注意如果后端接口是 HTTPS抓包工具需要装证书、开 HTTPS 解密否则看到的是加密流量。这中间还会涉及一些证书信任配置Windows 上比 Mac 上麻烦一些。抓包工具适合偶尔查一次不适合天天开着因为会拖慢请求速度还容易干扰其他联调。2.4 生产环境看 Nginx 转发日志开发环境能看到代理日志生产环境往往就没有 devServer 了。生产环境的前端静态文件部署在 Nginx 下请求通过 Nginx 反代到后端服务。这时候想要排查“真实地址”得看 Nginx 的转发日志。一个比较推荐的 Nginx 配置姿势在 location 里单独写日志log_format proxy_log $remote_addr $request $status $proxy_host $upstream_addr; location /api/ { proxy_pass http://backend_server; proxy_set_header Host $http_host; access_log /var/log/nginx/api_access.log proxy_log; add_header X-Backend-Server $upstream_addr always; }$proxy_host 是 proxy_pass 里配置的上游主机名和端口$upstream_addr 是 Nginx 实际连接到的上游地址和端口。如果后端是一个域名这俩可能不一样$upstream_addr 才是真实连到的那台机器。加 add_header X-Backend-Server 后前端在浏览器 Network 里就能直接看到响应头里有 X-Backend-Server: 10.0.0.5:8081 这样的信息非常直观。不过注意 add_header 要在有响应头的时候才会带而且如果后端本身设置了同名响应头Nginx 的配置可能不会覆盖需要 always 和合适的优先级。3. 代理配置里的“地址变形记”3.1 真实 URL 是这么拼出来的很多人在配置 pathRewrite 的时候是照抄模板根本没看明白它到底会拼出什么地址。实际上一条请求经过代理之后最终 URL 满足一个很简单的关系真实地址 target 原始请求路径经过 pathRewrite 处理后的路径举几个例子原始请求路径targetpathRewrite最终转发路径最终真实地址/api/user/listhttp://192.168.1.10:8081{^/api: }/user/listhttp://192.168.1.10:8081/user/list/api/user/listhttp://192.168.1.10:8081不写/api/user/listhttp://192.168.1.10:8081/api/user/list/api/user/listhttp://192.168.1.10:8081/backend{^/api: }/backend/user/listhttp://192.168.1.10:8081/backend/user/list/api/user/listhttp://192.168.1.10:8081{^/api: /v2}/v2/user/listhttp://192.168.1.10:8081/v2/user/list第三行是很多人会踩的坑。target 里带了 /backend 前缀再加上 pathRewrite 拼出来的 /user/list最终路径变成 /backend/user/list。如果后端路由没有这层前缀就是 404。所以排查真实地址的时候别只盯着 target 看要把 pathRewrite 的计算结果一起算进去。这也是为什么我强烈建议你在代理配置里把真实地址打印出来看一眼就省得手算了。3.2 changeOrigin 到底改了什么changeOrigin 这个名字容易让人误解以为它改的是请求来源 IP。其实它改的是 HTTP 请求头里的 Host 字段。默认情况下devServer 转发请求时Host 头保留的是浏览器当时请求的地址比如 localhost:8080。某些后端服务尤其是 Java 系的网关、基于虚拟主机的服务会根据 Host 头来路由或校验域名。你 Host 还写着 localhost:8080后端可能直接拒绝或者给你路由到默认站点去了。把 changeOrigin 设成 true 之后devServer 会把 Host 头替换成 target 里的 host。所以后端日志里看到的 Host 是 192.168.1.10:8081 而不是 localhost:8080这才是正常的。这同时也说明一个问题如果你在后端日志里看到了来源 Host 被改写不代表请求是“伪造”的这只是代理的标准行为。排查时不要因为 Host 不是 localhost 就觉得链路有问题。3.3 多环境切换 target 时怎么避免看错地址联调环境多了之后target 经常要在本地环境、测试环境、预发环境之间切换。我见过很多项目直接把 target 写死在 vue.config.js 里每次切环境就改一行代码然后重启特别容易出错。更稳的做法是用环境变量控制 target。Vite 项目里可以用 .env 文件# .env.development VITE_PROXY_TARGET http://192.168.1.10:8081// vite.config.ts const target env.VITE_PROXY_TARGET || http://localhost:8081Vue CLI 项目可以用 VUE_APP_ 前缀的环境变量在 vue.config.js 里通过 process.env 读取。这样切换环境之后配合上一节的代理日志你一眼就能看出当前真实地址是哪个环境。我自己的习惯是日志里把环境名也打出来比如[proxy][test]这样终端刷屏的时候不容易看串。4. 排查代理地址问题的实战速查4.1 代理生效了但一直 404这是最常见的现象Network 面板里能看到请求发出去了也有响应但状态码是 404。这种问题十有八九出在路径拼写上。排查思路是三步走看代理日志打印出的最终转发路径对比后端路由的真实路径检查 pathRewrite 是否多写或少写了前缀有一种特别隐蔽的情况target 本身带了路径前缀比如 http://192.168.1.10:8081/gateway然后你又在 pathRewrite 里把 /api 替换成空结果真实路径变成 /gateway/user/list后端如果没做相应匹配就 404。这种情况在代理日志里会非常明显。4.2 /api 前缀丢失或重复/api 前缀问题基本可以靠一条规则记清楚pathRewrite 的 value 是你希望“替换成什么”不是“去掉什么”。想去掉 /api写法是pathRewrite: { ^/api: }注意^符号它是正则里的“开头”锚点只匹配路径开头的 /api。如果不写^写成/api: 会把路径里所有出现 /api 的地方都替换掉比如 /user/apiList 也会被误伤。而如果后端接口本身就需要 /api 开头你就不写 pathRewrite让它原样转发。还有一种情况是重复了前端请求地址是 /api/user/listtarget 是 http://xxx:8081/apipathRewrite 又没写最终地址变成 http://xxx:8081/api/api/user/list这就是典型的“两层 /api”问题。4.3 五分钟定位一个会打印请求的假后端这个方法是我调试代理问题时最常用的。与其在那猜 pathRewrite 拼出来的地址对不对不如直接起一个会打印收到的所有请求的“假后端”。它不返回业务数据只负责把进来的请求原样显示出来。const http require(http) const server http.createServer((req, res) { console.log([ new Date().toISOString() ]) console.log(method:, req.method) console.log(url:, req.url) console.log(host:, req.headers.host) console.log(x-debug-real-url:, req.headers[x-debug-real-url] || -) console.log(---) res.setHeader(Content-Type, application/json) res.end(JSON.stringify({ code: 0, url: req.url, host: req.headers.host, headers: req.headers })) }) server.listen(8081, () { console.log(fake backend listening on 8081) })把代理的 target 指到 http://localhost:8081然后在浏览器里触发请求。终端会打印出每一跳的实际路径和请求头响应体里也直接能看到。这个假后端脚本我本地存了一份遇到路径问题随时起配合代理日志两头一对比问题马上定位。4.4 在 axios 拦截器里打印地址的意义和局限直接在 axios 请求拦截器里打印service.interceptors.request.use((config) { console.log([axios], config.method.toUpperCase(), config.baseURL config.url) return config })这个能做但你要清楚它打印的是什么。baseURL 一般是 /apiurl 是 /user/list拼出来是 /api/user/list。这个地址是“浏览器将要请求的地址”和浏览器 Network 面板里显示的一致但和代理转发后的真实地址是两码事。所以我不建议把 axios 拦截器的日志当作真实地址的依据。它适合用来确认前端代码层面的请求路径是否正确但如果要定位代理转发的问题还是看代理层的 onProxyReq 或 onProxyRes 日志更准确。前端代码、代理配置、后端路由这是三个不同的层级。排查问题时要先确定自己在哪一层别拿 A 层的日志去证明 B 层的问题。4.5 多环境联调时如何避免“看错地址”联调时最容易出的事故是你以为请求打到了测试环境但实际上代理 target 指到了预发环境然后你对着一堆错误数据排查了半天。我现在的做法是三层保险代理日志里打印完整真实地址环境名也带进去后端每个环境返回的响应头里带一个 X-Env 标识比如 X-Env: test前端在页面顶部用环境变量显示当前环境徽标三层一对照基本不会再看错环境。尤其现在很多公司后端环境很多dev、test、staging、prodtarget 配置一多人眼难免会看花。5. 再分享几个调试小习惯前面讲的是方法最后聊几个我在实际项目里攒下来的习惯不一定上得了什么台面但确实帮我省了不少事。第一个习惯是永远给代理日志加颜色和标识。终端刷屏的时候纯白字特别容易看漏。我会在打印真实地址的时候用\x1b[33m之类的 ANSI 色码给地址加个颜色或者至少加一个[proxy]前缀。这样日志多了也能一眼扫到关键信息。第二个习惯是保留响应头回传。前面 vue.config.js 里的 onProxyRes 会把 X-Proxy-Real-Url 写进响应头这样前端同事在 Network 面板里直接就能看到真实地址不用跑到终端去看。这个方法在多端联调小程序、App、Web 同时调时尤其有用因为不是每个人都能看终端。第三个习惯是善用假后端。遇到后端还没写好或者后端环境异常的时候假后端不只是用来验证路径的它还能模拟响应让前端先跑起来。我之前有几次前后端进度不匹配就用这个脚本把接口 mock 掉开发完全不受阻塞。第四个习惯是排查顺序固定下来。先确认 target 的地址能通curl target 地址能通再继续然后看代理日志里的转发路径再后看后端日志。这个顺序基本能覆盖 90% 的代理问题。很多同学一上来就改配置改完还是错就是因为没先确认 target 本身是不是好的。最后说一个小细节改了 vite.config.js 或 vue.config.js 之后一定要重启 devServer。Vite 对配置文件的热更新支持比较好但代理相关的某些改动不会完全生效Vue CLI 就更不用说了基本每次都要重启。我踩过好几次“改了半天没反应结果忘了重启”的坑现在每次改完配置第一件事就是重启然后再去触发请求。
