企业官网建设流程全解析

前两天群里有人问我一个问题：Vue 项目里配好了跨域代理，页面代码里请求写的是/api/v1/user，浏览器 Network 面板看到的也是/api/v1/user，可后端同事死活说没收到请求，这该怎么查？我说你先把“真实地址”找出来再说别的。很多人做 Vue 开发一两年，对请求代理的理解还停留在“配上能通就行”，真出问题就抓瞎。这篇文章我就把 vue 请求代理、查看真实地址这件事完整拆一遍，从浏览器、代理层、后端三层视角讲清楚，最后再给一套排障套路。不管你是刚入门的前端，还是已经在写业务的老手，照着做基本能把这类代理问题锁死在某一层。

1. 为什么要看清“真实地址”：一条请求的完整路径

1.1 代理只是“前台”，浏览器永远见不到后厨

要理解真实地址这个概念，得先把开发环境下的请求链路想明白。你在 Vue 项目里配置代理，本质上是启动了一个开发服务器（比如 Vite 默认的 5173 端口），浏览器发出的请求先到这台开发服务器，开发服务器再根据你配置的 proxy 规则，把这个请求转发到 target 指定的目标地址去。

举个例子，你本地 vite.config.js 里大概写着这样的配置：

server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }

浏览器里发起一个/api/login的请求，实际发生的事是：浏览器请求http://localhost:5173/api/login，开发服务器收到后，把路径重写成/login，再转发给http://localhost:3000/login。整个过程里，浏览器只知道自己请求了localhost:5173，它永远看不到localhost:3000这个真实后端地址。

用个生活化的类比：浏览器是访客，开发服务器是前台，后端是真正的办公室。访客进大门说“我找张三”，前台把张三叫出来，访客全程不知道张三工位在哪。你查“真实地址”，本质上是想搞清楚前台到底把访客带到哪了——这个过程，浏览器里直接看不到。

1.2 不看真实地址，你会掉的三个坑

我在带人的时候发现，不看真实地址带来的问题主要集中在三类，每类都能让你白加班好几个小时。

第一类是路径对不上。前端写的是/api/login，代理 rewrite 规则写错了，后端实际收到的是/api/login而不是/login，而后端路由只定义了/login，结果就是 404。你在浏览器里看 Network，显示的是localhost:5173/api/login，状态码是 404，你大概率会去怀疑后端接口写错了。

第二类是环境串了。有的项目 proxy target 写的是测试环境地址，你本地开发时接口全走测试库，改了半天数据发现线上还是老样子。这种问题如果不看真实地址，光看 Network 根本发现不了，因为浏览器显示的始终是localhost:5173。

第三类是跨域问题没解决透。changeOrigin 没配或者配错，后端收到的 Origin 还是http://localhost:5173，后端做了跨域校验就直接拦了。这种报错现象像是 CORS，但根因在代理层。

说白了，看真实地址不是炫技，而是为了快速回答一个问题：这个请求到底被代理转发到了哪个主机、哪个端口、哪个路径。搞清楚了这个，后面所有排查才有方向。

2. 第一层：在浏览器里把能看到的都看明白

2.1 Network 面板里的 Request URL，并不是真实地址

先说操作最零门槛的一层：打开浏览器 F12，切到 Network 面板，刷新页面，找到对应的请求，点击后在 Headers 里能看到 Request URL。

很多新人到这里就卡住了：明明显示的是http://localhost:5173/api/login，这就是真实地址啊？不对。这个地址只是开发服务器的地址，它只证明了一件事：浏览器把请求发给了开发服务器，代理有没有转发、转发到了哪里，这一层完全看不出来。

我一般会再点开这个请求，往下看 Request Headers 里的 Host 字段。Host 显示的是localhost:5173，说明请求头目标还是开发服务器。如果代理配置正确，后端拿到的 Host 应该是 target 的地址（当然这取决于 changeOrigin 配置，后面细说）。

还有一个细节希望你能养成习惯：去看 Response Headers。如果这个请求真的被代理转发了，返回内容来自后端，响应头里通常会带后端框架的特征字段，比如X-Powered-By: Express、Server: nginx/1.18之类的。如果你请求的是静态资源或前端路由 fallback，返回的响应头就是开发服务器的默认值。这个小细节，能帮你快速判断这个响应到底是谁给你的。

2.2 通过响应头和耗时，判断请求到底去了哪儿

有人可能会问：如果后端也是 Node 写的，返回头可能没有明显特征，那怎么看？

那就看时间。本地开发时如果后端跑在同一台机器上，代理转发是一个内网回环，响应时间通常只有几毫秒到几十毫秒。如果你的项目里某个请求的 Waiting (TTFB) 时间飙到了几百毫秒甚至一秒以上，八成代理 target 指向的是远程服务器，比如测试环境或者公网接口。

Time 那一列同样有用。点开请求的 Timing 标签页，能看到 Stalled、Request sent、Waiting 等阶段。Stalled 时间过长通常说明浏览器连接数受限，或者代理在做额外处理；Waiting 时间是后端实际处理时间。如果你发现 Waiting 特别长，而后端本地日志显示处理很快，那就要怀疑请求是不是被代理到了别的地方。

这个方法不绝对，但在没有其他工具的情况下，是最快能从现象上判断代理去向的手段。我建议你把浏览器这层当成第一道筛查，症状明显就直接去下一层，不要在这里耗太久。

2.3 想看得更细：断点、复制为 cURL、Initiator

有些人 Network 面板看半天还是心里没底，这里再给你三个进阶操作。

第一个是右键请求，选择 Copy，再选 Copy as cURL。这个命令会把请求的完整格式导出来，包括 URL、请求头、请求体，直接拿到终端里执行。执行结果能帮你模拟浏览器发出的那个请求，看是不是真的能通。不过要注意，这里复制的 URL 还是开发服务器的地址，不是 target 地址，它能帮你验证的是“开发服务器这个口子通不通”。

第二个是看 Initiator 标签页。它会列出这个请求是由哪段代码发起的，精确到文件名和行号。点击进去可以直接跳到源码位置。这个方法适合项目里请求很多、你不知道某个接口到底在哪里触发的情况。

第三个是直接在 xhr/fetch 相关位置打断点。在 Sources 面板里按 Ctrl+Shift+F 搜索你的接口路径，找到发起请求的那一行，打上断点。请求发出去之前，在 Console 里打印一下请求配置对象，比如 axios 的 config，看里面的 url 和 baseURL 是怎么拼的。这一步能帮你确认，前端代码里组装出来的地址到底长什么样。

不过到这里你也会发现，不管在浏览器里怎么折腾，都看不到代理转发后的真实地址，因为代理转发是开发服务器做的事，浏览器不参与。所以接下来必须换视角。

3. 第二层：从后端日志里捞真实请求

3.1 Express 五分钟加个日志中间件

最直接的办法是让后端把收到的请求打出来。如果你后端用的是 Express，在入口文件最前面加一个中间件：

const express = require('express'); const app = express(); app.use((req, res, next) => { console.log(`[REQ] ${req.method} ${req.url}`); console.log(`host: ${req.headers.host}`); console.log(`origin: ${req.headers.origin}`); console.log(`user-agent: ${req.headers['user-agent']}`); next(); }); // 你的路由 app.get('/login', (req, res) => { res.json({ code: 0 }); });

重启后端服务，再在前端触发一次请求，看后端终端输出。你会发现一个很有意思的事：如果代理配置正确且 rewrite 生效了，后端打印出来的 URL 是/login，而不是/api/login；Host 字段可能是localhost:3000（取决于你的监听地址和端口），也可能是localhost:5173（这就是 changeOrigin 没开的效果）。

这个日志的价值在于，它直接暴露了后端视角下的请求长什么样。我之前排查过一个前后端联调问题，前端说接口报 404，后端说日志里根本没有请求，两边僵持不下。结果加上这个中间件一跑，才发现代理 target 写的是一个没启动的端口，请求全打在代理层就失败了，根本到不了后端。

3.2 Vite / Webpack 代理层打印转发日志

如果后端不方便加日志（比如你调的是第三方接口），那就把日志加在代理层。Vite 项目可以写一个极简插件，在请求进入开发服务器中间件时打印：

// vite.config.js function proxyLogPlugin() { return { name: 'vite-proxy-log', configureServer(server) { server.middlewares.use((req, _res, next) => { if (req.url.startsWith('/api')) { console.log(`[vite-proxy] original URL => ${req.url}`); } next(); }); } }; } export default defineConfig({ plugins: [proxyLogPlugin()], server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } });

这个插件在开发服务器接收到请求、但还没执行代理转发之前打印 URL，所以你看到的是 rewrite 之前的原始路径。如果想确认 rewrite 之后转发到什么地址，可以再写一个带 http-proxy 中间件监听事件的方式，但日常调试其实用不到那么深。

Webpack 项目则是在 devServer 配置里加钩子：

devServer: { proxy: { '/api': 'http://localhost:3000' }, onBeforeSetupMiddleware(devServer) { devServer.app.use((req, res, next) => { if (req.url.startsWith('/api')) { console.log(`[webpack-proxy] ${req.url}`); } next(); }); } }

这类日志打出来的内容虽然只有一行，但信息量很大：它能确认请求到底有没有到达开发服务器、有没有走代理规则。如果这里连日志都没有，说明浏览器根本没把请求发到开发服务器，问题出在前端代码层面。

3.3 本地透传服务：把请求原样看一遍

后端不方便加日志，代理层又看不出最终转发目标的完整信息时，我还有一个终极大法：本地起一个 Node 透传服务，让代理 target 指向这个服务，服务把请求完整记录下来，再转发给真实后端。

const http = require('http'); http.createServer((req, res) => { console.log('[capture]', req.method, req.url); console.log('[headers]', JSON.stringify(req.headers, null, 2)); const proxyReq = http.request({ host: '127.0.0.1', port: 3000, path: req.url, method: req.method, headers: { ...req.headers, host: '127.0.0.1:3000' } }, (proxyRes) => { res.writeHead(proxyRes.statusCode, proxyRes.headers); proxyRes.pipe(res); }); req.pipe(proxyReq); }).listen(9527); console.log('capture server running at 9527');

然后你把 vite.config.js 的 proxy target 改成http://localhost:9527，真实请求就会先打到这里打印一遍，再被转发到 3000 端口的真实后端。

这里有几件事要提醒你：第一，转发时要把 Host 头改成后端地址，否则后端可能因为 Host 不匹配拒绝请求；第二，这个服务只是调试辅助，用完记得改回代理配置，别留着上生产；第三，如果请求体很大，这个简单转发也是能把数据传过去的，但你要是用到上传大文件，还是直接看代理日志省事。

这个方案看起来笨，但胜在一目了然。多人协作时，后端不给你权限看日志，你就用这一招自主排查，效率极高。

4. 第三层：在前端代码里主动打印请求地址

4.1 axios 拦截器能打印出什么

前面讲的是从外部看请求，现在说怎么在代码内部看。

如果你用 axios 发请求，直接写一个请求拦截器打印配置：

import axios from 'axios'; axios.interceptors.request.use((config) => { const fullURL = `${config.baseURL || ''}${config.url}`; console.log( `[axios] ${(config.method || 'get').toUpperCase()} ${fullURL}`, config ); return config; });

这里有个认知误区得先说清楚：axios 的 baseURL 和 url 拼接出来的地址，就是发送给开发服务器的地址，比如http://localhost:5173/api/login或者相对路径/api/login。它同样不是代理转发后的真实地址，因为代理转发发生在开发服务器内部。

那这个打印有什么用？它的价值在于验证“前端代码组装的 URL 是否符合预期”。比如你发现请求路径里多了一个双斜杠、或者 baseURL 以/结尾而 url 以/开头导致路径变成//api//login，这种问题在代理层之外就会出现，拦截器打印能第一时间暴露。

另外需要注意，config.baseURL可能没设置，也可能设置的是完整域名。如果你在 baseURL 里写了http://localhost:3000，那请求反而绕过了代理，直接跨域了。这种情况拦截器打印出来后一眼就能看出来。

4.2 fetch 全局监听，第三方请求也跑不掉

有些项目会引入第三方 SDK，比如地图 SDK、数据上报 SDK，它们内部用 fetch 发请求，axios 拦截器管不到。这时候可以在开发环境做一次全局的 fetch 包装：

if (import.meta.env.DEV) { const originalFetch = window.fetch; window.fetch = function (...args) { console.log('[fetch]', args[0], args[1] && args[1].method); return originalFetch.apply(this, args); }; }

这样所有经过 fetch 发出的请求，浏览器都会在 Console 里打印出来。配合 Network 面板的 Initiator，基本能把项目里所有的网络请求来源都摸清楚。

注意这个方案是干扰性的，生产环境绝对不能带，所以我一般会先用import.meta.env.DEV（Vite 项目）或process.env.NODE_ENV !== 'production'（Webpack 项目）把代码包起来，防止上线时误进去。

4.3 生产环境：从 Nginx 日志和环境变量定位

开发环境有代理，生产环境通常用 Nginx 做反向代理。此时浏览器 Network 面板里看到的地址就是生产域名，比如https://yourdomain.com/api/login，而 Nginx 内部转发的 target 也看不到，但排查思路是一样的。

生产环境我常用的做法是查 Nginx access log 和 error log。access log 里记录了 Nginx 收到的所有请求，包括时间、IP、请求路径、状态码；error log 里则能看到代理转发失败时的具体原因，比如connect() failed、upstream timed out之类的关键信息。

还有一个小技巧：用环境变量管理不同环境的接口地址。Vite 项目里可以这样：

// .env.development VITE_API_BASE = '/api' // .env.production VITE_API_BASE = 'https://api.example.com'

这样开发环境和生产环境走完全不同的请求链路，不容易串环境。页面构建后，可以在页面上把当前的import.meta.env.MODE和VITE_API_BASE显示出来，调试时一眼就知道自己连的是哪个环境。这个习惯帮我避过很多“数据怎么跟线上不一样”的坑。

5. 实战速查：常见问题与定位套路

5.1 高频症状对照表

把这几类问题整理成一个速查表，排查时直接对照：

这张表不追求覆盖所有场景，但它对应的几种情况，基本包含了日常开发中 90% 的代理问题。遇到问题先对号入座，能少走很多弯路。

5.2 一次 404 问题的完整复盘

前阵子帮同事排查过一个案例，现象很典型：前端 Vue3 + Vite，请求/api/login，浏览器 Network 显示 404，响应内容是“Cannot POST /api/login”这种 Express 默认的 404 文案。

我第一反应就是后端收到的路径不对。让同事在后端入口加了个打印中间件，确认后端实际收到的是/api/login，而后端路由写的是app.post('/login')，所以 404。问题出在 vite.config.js 里的 rewrite 没配：

proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true // 缺少 rewrite: (path) => path.replace(/^\/api/, '') } }

修复方式就是补上 rewrite 规则。这个案例里如果只看浏览器 Network，很容易误判成“后端接口不存在”，但实际上路径只差一个前缀。所以我的习惯是：任何时候看到 404，先到后端打印一次实际收到的路径，再讨论路由对不对。

另一个案例是代理 target 写错。同事把 target 写成了http://localhost:3000/，结尾多了个斜杠，本地服务一直报错。这种不起眼的细节，不靠代理层日志或者透传服务，很难一眼发现。加上日志后，Vite 的 proxy 转发时会因为地址拼接问题抛异常，或者干脆请求不到目标服务，日志里会留下明确记录。

5.3 我的三层验证法

排查多了之后，我总结出一套固定流程，在这里分享给你。

第一层：浏览器 Network 面板看 Request URL，判断请求有没有到达开发服务器。如果 Network 里连请求都没有，说明前端代码就没发出去，问题出在业务代码上。

第二层：代理层日志或者本地透传服务，看 URL 和 target。这个环节能确认请求从开发服务器出来后往哪走、路径重写成什么样。Vite 插件里那几行打印代码，我一直留在项目里，只在开发环境启用，排查问题特别方便。

第三层：后端入口日志，看后端实际收到的 method、url、host、origin。这一步是最有说服力的，因为它是整条链路的终点站。后端说什么都没收到，那就回到前两层找问题；后端收到了但响应不对，那就不是代理的事，该排查业务逻辑。

三层对完之后，问题归属基本就死了：是前端拼错路径，还是代理配错规则，还是后端接口本身有问题。剩下极少数是网络层面的问题，比如本机 hosts 解析、防火墙拦截，那时候再去单独排查。

最后说点个人感受：我之前也沉迷过各种高端的调试工具和插件，后来发现解决代理问题最有效的就是这些笨办法——多打日志、多看每一层实际收到的请求。你把每一层的输入输出搞清楚，复杂问题立刻就变得简单了。如果你也被 vue 请求代理的问题折磨过，建议先别急着改代码，把浏览器、代理、后端三层的日志都打开，把请求走过的每一步看清楚，答案往往就藏在其中某一层里。