前端网络排障必学：用 Network 面板看清每一次请求

开发这几年我养成了一个习惯：遇到网页出问题，先不急着改代码，先把 F12 打开，切到 Network 面板看一遍。很多前端同事觉得 Network 面板只是"看请求通没通"用的，其实不是这样——它真正厉害的地方，是能把浏览器和服务器之间那些看不见的交互，变成一条条可追溯的记录。你看到的每条请求、每个状态码、每段瀑布时间，都是破案的线索。这一期是 Ep.02，标题叫"侦察兵的艺术"，想聊的就是：怎么把 Network 面板当成你手里那副望远镜，从那些平常没人注意的请求细节里，看清网站背后到底发生了什么。

不管你是做 Vue、React 还是原生页面，不管你遇到的是接口 404、媒体文件加载不出来、WebSocket 反复重连，还是别人嘴里说的"网络不可用"，只要你愿意把 Network 面板拆开看，大多数问题都能在五分钟内收敛到明确的方向。这篇文章会按我的实际排障经验，从面板基本操作讲到时间线指标，再用几个真实场景把完整排查链路走一遍。看完之后，你对"网络问题"的判断会变得很具体。

1. 为什么说 Network 面板是前端的第一侦察工具

1.1 它其实一直在记录，只是你没注意

很多人第一次打开 Network 面板，是因为后端同事说"你调一下接口看看吧"。但其实 Network 面板默认就在后台记录浏览器发出的所有网络活动，并不是一定要手动开启才能用。你在页面里点击、滚动、刷新、上传文件、切换路由，只要有请求发生，记录区就会实时滚出新的行。

打开方式不用多说了：浏览器里按 F12，或者右键页面选"检查"，然后顶部找到 "Network" 标签页。Windows 上也可以用 Ctrl+Shift+I，Mac 上用 Option+Command+I，都很快。要提醒的一点是，如果你一直开着 DevTools，但又切到别的标签页操作了很久，回来时记录可能已经清空了——因为 Network 面板默认是"导航即清空"的逻辑。真正需要长时间观察时，记得把面板左上角的 "Preserve log" 勾上，页面跳转后旧记录还会保留，这对排查登录跳转、302 循环、单页应用路由切换这类问题特别有用。

还有一个容易被忽略的开关：面板顶部那个红色圆点。它代表"正在录制网络日志"。如果你不小心点了它，记录会暂停；如果页面有异常但 Network 里一片空白，先检查红点是不是灰了。这听起来很基础，但我真的见过同事排查半天，最后发现是误触了录制开关。

1.2 默认表格里每个字段都是一条线索

Network 面板默认展示的是请求列表，每一行代表一次完整的网络请求。默认列有 Name、Status、Type、Initiator、Size、Time 和 Waterfall，很多人的使用习惯就是只看这几列，能查出来的东西十分有限。

我给你一个很实际的建议：在列表的表头任意位置右键，勾选出更多列，至少把 Domain（域名）、Remote Address（远程地址）、Protocol（协议版本）、Connection ID（连接编号） 打开。为什么这几列有用？因为你在做移动端联调、本地开发、线上环境对比的时候，最常遇到的情况是"明明同一个接口，在不同环境表现不一样"。Domain 列能告诉你请求最终打到了哪个域名，Remote Address 列能告诉你这个域名被解析到了哪个 IP，Protocol 列能看出资源走的是 HTTP/1.1 还是 h2（HTTP/2）。有时候页面加载慢，看一眼 Protocol 会发现大量请求都挤在 HTTP/1.1 的 6 条连接里排队，这比单纯看某个请求的耗时更接近根因。

列表默认按发生时间排序。请求名的显示规则是资源 URL 的最后一段。如果有人跟你说"Network 面板怎么看不到 xxx 接口"，先別急着怀疑代码，直接在顶部过滤框里输入接口关键字就够了。过滤框是 Network 面板最常用的入口，别只在列表里肉眼滚动。

1.3 它更适合回答哪些问题

我总结过 Network 面板最适合回答的四类问题：

1. 这个请求到底有没有发出去。 如果 Network 里根本没有请求记录，说明问题大概率出在代码逻辑、触发时机、路由守卫这类前端环节；不用先去冤枉后端。
2. 请求发出后发生了什么。 状态码 200、304、404、500，分别对应完全不同的处理路径；状态码前的 (canceled)、(failed)、(blocked:...) 也有各自的含义。
3. 请求慢在哪一段。 是域名解析慢，是 TCP/TLS 连接慢，还是服务器迟迟不返回第一个字节？这就是瀑布图要回答的问题。
4. 浏览器到底用了缓存还是真的走了网络。 Size 列里的 (from disk cache)、(from memory cache)、(from service worker)，就是这条请求的最终来源。

当你心里装着这四个问题再去看 Network 面板，它就不再是"一个看接口响应的窗口"，而是一个帮你缩小排查范围的侦察工具。

2. 一次完整侦察：从请求列表到响应体

2.1 先学会从列表快速锁定目标

排查问题第一步是找到目标请求。Network 面板顶部有个输入框，你可以直接输入关键字过滤 URL。除了文本过滤，点击输入框左侧的下拉箭头，还能按资源类型筛选，比如 Fetch/XHR、JS、CSS、Img、Media、Font、Doc、WS 等。这里的重点是：不一定非要在 All 场景下看列表，判断接口问题和页面资源问题应该用不同视角。

例如排查"接口返回 500"，先把类型切到 Fetch/XHR，再看列表。这样其他图片、字体、埋点请求不会干扰视线。排查"视频加载不了"，切到 Media 或者直接输入视频文件名，能看到浏览器对媒体文件的 Range 分段请求到底成没成功。排查"HMR 热更新断开"，就要切到 WS 看 WebSocket 连接状态。

进到具体请求行之后，最容易被戳到的入口是 Initiator（发起者） 列。它不只是告诉你"这是一个 XHR 请求"，还包含调用来源位置。点击 Initiator 里的链接，Chrome 会直接跳转到 Sources 面板，并把触发这个请求的那行代码高亮出来。如果你的源码有 sourcemap，甚至可以看到是 Vue/React 组件里哪个方法发起的请求，这一招在查"哪个组件悄悄拉了一个接口"的时候非常顺手。

2.2 点进详情之后要按什么顺序看

选中任意一条请求，右侧会出现详情面板。默认情况下，详情面板使用 Headers、Payload、Preview、Response、Initiator、Timing、Cookies 这几个标签页来组织信息。我的查看顺序是固定的，推荐你也这么养成习惯：

Headers 里的 General 区域是最先要看的。它会告诉你完整 URL、请求方法、HTTP 状态码、Remote Address、Referrer Policy。比如你发现接口实际返回的 URL 和你预期的不一样，那就是浏览器最终请求的地址有嵌套重定向；如果你在代码里写的是 /api/user，但 General 里显示 http://localhost:8080/api/user，这说明有代理或者 baseURL 在起作用。

请求头和响应头里，我习惯重点检查这几种：Content-Type、Access-Control-Allow-Origin、Cache-Control、ETag、Set-Cookie。这几个头几乎能解释前端一半以上的"玄学问题"：为什么跨域了、为什么浏览器没发新请求、为什么登录态丢了。

Payload 页签要看请求最终发送出去的数据，而不是代码里写在对象里的数据。有时候你自以为提交的是 { "userId": "123" }，实际因为序列化问题，接口收到的是 userId=123 或者空字符串。这里面如果填了 form 表单，还会区分 query string parameter 和 payload，注意别搞混。

2.3 状态码和 Size 列的信息量

列表里的状态码看着只是一个数字，实际上它会告诉你很多潜在的判断分支。200 不一定代表内容正确，只是这次 HTTP 交互成功；204 表示没有任何响应体；304 表示浏览器缓存生效，服务器没有返回新 body；301/302 表示发生了重定向，你要看 Response Headers 里的 Location；403/404/500 则要再结合响应体判断是权限、路由还是服务器内部问题。

Size 列更值得玩味。网络请求的 Size 列可能显示为两种格式，例如 10.2 KB / 12.1 KB，前面是传输大小，后面是资源解压后的大小。如果压缩生效，你会看到传输大小远小于解压后大小。如果后面跟着 (from memory cache) 或 (from disk cache)，说明浏览器根本没发起新请求，直接用缓存了；如果带着 (from service worker)，说明请求被 Service Worker 拦截了。这些括号里的信息，比单纯看左上角转圈更接近真相。

有一次帮人排查线上接口偶发超时，所有人都在看服务器 CPU，结果我把 Network 列表打开，发现这个接口不是每次刷新都发请求，浏览器直接给了 (from memory cache)。也就是说，用户看到的"偶发问题"根本不是接口慢，而是缓存和真实请求在交替，导致页面数据新旧不一致。解决方向瞬间从后端性能调优转到了前端缓存策略。

3. 真实场景案例：用 Network 面板定位几个常见"网络故障"

3.1 Vue 项目启动后 Network 不可用

搜索热词里有一条很典型："vue项目启动后network不可用"。先别急着在浏览器里 F12，这条问题通常不是浏览器 Network 面板坏了，而是开发服务器启动日志里的提示：

code复制VITE v5.2.0 ready in 1532 ms

➜  Local:   http://localhost:5173/
➜  Network: use --host to expose

有些老版本 Vue CLI 会直接打印 App running at: Local: http://localhost:8080/ Network: unavailable。这个 "Network: unavailable" 代表的是：开发服务器目前只监听了本地回环地址 127.0.0.1，没有对外开放可访问的局域网地址。也就是说，只有你这台电脑能用 localhost 打开，手机或其他设备访问 http://192.168.x.x:8080 是不通的。

为什么服务器默认只监听 localhost？其实是开发框架的安全设计——端口默认不应该向局域网开放，避免别的设备随意访问你正在开发的机器。如果你确定需要真机调试，或者需要用另一台机器访问，方向就不是去浏览器 Network 面板找问题，而是把开发服务器绑到所有网卡上：

js复制// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    host: true,
    port: 5173
  }
})

Vue CLI 项目可以临时在命令行里带参数：

bash复制npm run serve -- --host 0.0.0.0

改完配置重启后，终端会打印出 Network: http://192.168.x.x:5173/。此时再用其他设备访问这个地址，浏览器 Network 面板里才能看到有效请求。如果地址还是显示不出来，下一步用系统命令查一下本机 IP：

• Windows：ipconfig，看 IPv4 地址；
• macOS/Linux：ipconfig getifaddr en0 或 ip addr。

如果你在 Windows 上发现本机网络图标一直提示无 Internet，但 localhost 又能跑，先检查两个系统服务：Network List Service 和 Network Location Awareness。用 Win + R 打开 services.msc，找到这两项，确认启动类型是自动且当前状态为"正在运行"。这两个服务负责让系统正确识别当前网络是专用网络还是公用网络，如果它们停了，Windows 防火墙可能把当前网络误判为公用网络，导致局域网里的其他设备连不进来。它们不是浏览器 Network 面板的组成部分，但经常成为"整个网络不可用"的隐藏推手。

提醒：别为了让手机连上开发服务器就随手关掉 Windows 防火墙。正确做法是只放行 Node.js 或指定端口，并且把当前 Wi-Fi 网络类型改为"专用网络"。

3.2 HMR 反复重连，控制台出现 waiting for network connection failed

搜索结果里还有一句很典型的报错：reconnecting... waiting for network connection failed: error sending request。这类情况常见于前端开发服务器和浏览器之间的热更新通道断了。

开发时页面和 Vite/Vue CLI 之间通常有一条 WebSocket 长连接，用于推送模块更新。这条连接断了，你在编辑器里改完代码，页面不会热更新，控制台还会反复出现重连提示。很多人第一反应是去调 HMR 配置，但正确排查姿势是先打开 DevTools 的 Network 面板，把筛选类型切到 WS，然后刷新页面。

正常情况下列表里会有一条 WebSocket 记录，状态码是 101 Switching Protocols。点开它，还能在 Message 页签里看到建立连接后交互的帧数据。如果这条记录压根不存在，说明 WebSocket 握手请求在生产服务器或者反向代理层就被挡掉了；如果状态码是 404 或 502，说明服务器没有正确的升级处理逻辑；如果状态码是 101 但后面又频繁断开，那问题可能出在闲置超时、代理空闲超时或者消息心跳上。

我遇到过一次典型的代理场景：前端页面跑在测试环境域名下，Nginx 只代理了 HTTP 的 / 路径，却没有把 WebSocket 的 Upgrade 请求头正确转发到开发服务器，导致浏览器每次握手都收到 404。页面本身能打开，但一旦我改动代码，热更新通不过。排查时就是靠 Network 面板确认握手请求返回 404，再去看服务器配置，一找一个准。

如果你只是临时想快速恢复页面操作，又没空深究代理配置，可以在 Vite 配置里把 HMR 关掉，让每次保存都走整页刷新：

js复制// vite.config.js
export default defineConfig({
  server: {
    hmr: false
  }
})

这不是长期方案，但能在联调时省下很多"改了没生效"的困惑。

3.3 媒体加载失败：the media could not be loaded

另一个高频报错来自 HTML5 播放器：The media could not be loaded, either because the server or network failed or because the format is not supported. 看到这行英文，先不要急着怀疑浏览器不支持视频格式，而是需要打开 Network 面板，按资源类型筛选到 Media，找到对应视频请求，然后看三个信息。

第一，看状态码。如果媒体文件返回了 403 或者 404，说明视频路径根本不对，需要检查资源部署、鉴权或防盗链的 Referer 限制。第二，看 Response Headers 里的 Content-Type，如果是 application/octet-stream 而不是 video/mp4，服务器可能没有正确配置 MIME 类型，浏览器会拒绝按媒体文件解析。第三，也是最容易被忽略的，看请求头里有没有 Range: bytes=0-。

浏览器播放视频时通常会通过分段请求来拉取数据。如果服务器不支持 Range，返回了完整文件而不是 206 Partial Content，浏览器在快进、拖动播放条时就会出现播放失败或卡死。Network 面板中，正常的视频分段请求状态码应该是 206；如果你看到的是 200 OK，那说明你需要在服务器或反向代理层开启 Range 支持。很多临时写出来的静态服务器会忽略对 Range 的处理，这就是"本地播放没问题、部署到测试环境就挂"的经典原因。

另外，媒体加载失败还有一个常见伪装：视频请求本身看起来返回了 200，但响应体是 JSON。这种情况通常发生在接口层没有正确处理媒体流，或者开发服务器把视频路径误代理到了某个 API 网关，返回了一串错误提示。点开 Preview 页签看一眼内容，真相往往就在那里。

3.4 跨域失败的完整判断链路

跨域报错是 Network 面板最值得深挖的场景之一。控制台里的报错信息会告诉你 CORS policy 有问题，但不会告诉你该从哪里改。正确路径是：先在 Network 面板里找到那条跨域请求，看它是红色失败状态，还是成功 200 状态——是的，有时请求本身成功了，但浏览器因为响应头里缺少 Access-Control-Allow-Origin，把响应"拦在了门外"，前端拿不到数据。这种"请求成功但前端报跨域"的情况，Network 面板里的表现常常是：状态码为 200，但 Console 里有 CORS 错误。此时你去看 Response Headers，如果服务器没有返回 Access-Control-Allow-Origin，问题出在服务端响应头配置；如果请求类型是复杂请求，还要先看有没有 OPTIONS 预检请求，预检是否返回了 204 或 200。

遇到跨域问题时，很多人会直接复制网上推荐的代理配置或者后端注解，但通过 Network 面板你才能判断到底是"请求没发出去"还是"响应头缺失"，这两种情况的修改位置完全不同。

3.5 谷歌学术提示 your computer or network may be sending automated queries

搜索词里还出现了一句很长的英文提示，大概意思是"你的电脑或网络可能正在发送自动化查询"。这种页面一般不是浏览器前端代码出错，而是访问方 IP 或浏览行为被目标服务判定为高频自动请求，服务器主动弹出了安全验证页。你可以通过 Network 面板看到这个页面对应的请求状态码通常是 429、403 或者其他拦截类状态，响应体是一个 HTML 验证页面。

这背后的原因很多，有可能是某个脚本在偷偷触发搜索，也有可能是同一出口 IP 的请求量过大。这个场景本身和 Web 开发调试的关联度不高，但它是一个很好的案例：以后遇到任何"页面没显示正常内容"的问题，都应该先看 Network 面板里这条页面请求的真实响应是什么。如果响应体里是一段与预期完全不同的 HTML，那问题根本不在你的前端代码，而在请求链路被前置拦截了。

4. 瀑布图里的时间线：别把"慢请求"都说成后端慢

4.1 每个时间段分别代表什么

很多人看 Network 面板只关心 Time 列的总耗时，其实真正的性能判断藏在 Waterfall 瀑布图和时间明细里。点击任意请求，打开 Timing 标签页，你会看到浏览器把一个请求按阶段拆开了。每一段都有明确含义，我在下表里做了对比整理：

我们平时说的"接口很慢"，90% 的锅都在 Waiting (TTFB) 这一项。它代表的是浏览器已经把请求发出去了，但迟迟没有收到服务器的第一个字节。这一阶段的长短，主要受服务器业务处理速度和网络延迟影响。如果一个接口 TTFB 是 1 秒，Content Download 只有 20ms，那就别再去压缩前端代码了，得去查数据库查询、后端日志或者第三方依赖的响应速度。

反过来，如果 Content Download 很长，说明响应体大或者网络带宽被占满。此时看响应头里的 Content-Encoding 就知道有没有开启 gzip/brotli 压缩。一个 2MB 的 JSON 如果没走压缩，Content Download 会非常难看；开了压缩之后，传输体积可以降到几百 KB，下载耗时骤降。

4.2 一个请求慢、多个资源慢，处理方向不一样

判断慢请求要分场景：只有某一个接口慢，和整个页面加载都慢，处理思路完全不同。单个接口慢，优先看 TTFB 和响应体大小；整个页面资源都慢，优先看有没有大量同域请求在 HTTP/1.1 里排队，或者某个关键 JS 把后续请求堵在了后面。

举个实际例子：有次我负责的页面白屏时间很长，Network 面板里发现首屏需要加载 80 多个小图标，全部走 HTTP/1.1，Waterfall 上能看到一串请求排队。浏览器对同一域名下的 HTTP/1.1 连接数默认只有 6 条，超出部分必须排队等待前面的请求释放连接。即使每个图标只有 1KB，排队时间也比实际下载时间多得多。后来我把这些小图标做成了雪碧图并用 CSS background-position 切图，再配合资源预加载，排队现象直接消失。这类问题用服务器性能工具很难查到，但在 Network 面板的时间线里一目了然。

还有一类问题是水流量和请求优先级。在 Network 面板里，有时候会看到一个图片请求的 Queueing 特别长，但它的文件并不大，很可能是浏览器把它的优先级设成了 Low，被其他更高优先级的 CSS 和 JS 排到了后面。此时不一定需要改代码，可以先看看请求列上的 Priority 字段，判断资源调度是否合理；如果不合理，再考虑用 <link rel="preload"> 或者调整资源加载时机。

4.3 模拟弱网时应该怎么设参数

Network 面板顶部有 throttling 下拉菜单，默认是"在线/No throttling"。要模拟弱网，通常选择 Fast 3G 或 Slow 3G。很多前端只把节流当成"测加载效果"的工具，其实它更大的价值在于暴露代码里未处理的异步问题：弱网下请求返回慢，用户快速点击页面，会导致重复请求、竞态条件或者超时没有提示。

做移动端 H5 时，我习惯同时打开 Network 面板的节流和 CPU 降速。如果你在 DevTools 里按 Esc 打开下层抽屉，选择 Rendering，再在 CPU 选项里选择 4x slowdown，可以模拟低端安卓手机的渲染速度。搭配弱网环境一起做一次完整操作流程，很多"线上偶现、本地复现不了"的问题都会冒出来。

节流还有一个使用技巧：在本地开发时要验证一个接口是否走了缓存，可以把节流设为 Slow 3G，然后看第二次请求的 TTFB 和 Content Download 是否明显变短。如果完全没变短，说明浏览器没有缓存有效，需要检查 Cache-Control 和其他缓存头；如果第二次请求走了 cache，就能看到 Size 列出现 (from disk cache) 或 from service worker。

5. 容易被忽略的探测技巧：禁用缓存、过滤语法与数据导出

5.1 "Disable cache" 到底在哪，勾了之后有什么效果

很多人在搜索 Network 面板的 "Disable cache" 选项在哪。它在 DevTools 打开并切到 Network 标签页后的主工具栏上，一般在红色录制按钮、清空按钮、过滤框这一排的右侧，是一个复选框，文字直接叫 Disable cache。不同浏览器的位置可能有点浮动，但基本不会藏到二级菜单里。

这个选项的意思是：只要 DevTools 处于打开状态，浏览器就不再使用 HTTP 缓存，所有资源都会重新走一遍网络请求。它特别适合在改完 CSS、JS 但页面看起来没变化时使用。前端常见的"我改了代码为什么不生效"问题，很多并不是热更新坏了，而是浏览器本地缓存