一次接口问题的排查，通常要跨四段路：请求到底发出去了没有、发出去的参数和你以为的是否一致、长连接是断在握手还是断在保活、以及服务端拿到的客户端标识说明了什么。
这四段各有各的坑，而且大多不是代码写错，是对协议边界的理解差了一点。下面按排查顺序展开。这类工具的请求都由你的浏览器直接发出，不经过本站服务器中转，接口地址、Token、请求体都不会被记录，代价是必须接受浏览器的一整套安全限制。
一、浏览器里发请求的第一个现实约束是 CORS
这一点必须先讲清，否则后面所有「明明能通、工具里就是不行」的现象都无法解释。任何在页面里用 fetch 或 XMLHttpRequest 发出的跨域请求，都受同源策略约束：协议、域名、端口三者任一不同即为跨域，此时浏览器要求目标服务端主动返回 Access-Control-Allow-Origin 等响应头来放行，否则响应会被浏览器拦下不交给页面。
关键在于「拦下」的时机。请求其实已经发出、服务端也已经处理，只是响应不给你看。所以在HTTP请求模拟里遇到失败时，判断顺序是：
- **控制台里出现
blocked by CORS policy**：服务端没放行，和你的参数写法无关。这是目标接口的配置问题，不是工具的问题。 - **请求带自定义头或用了
PUT、DELETE、PATCH**：浏览器会先发一个OPTIONS预检请求，服务端必须正确响应预检并在Access-Control-Allow-Headers里列出你用的头，否则真实请求根本不会发出。带Authorization头的调试失败，八成卡在这里。 - 需要带 Cookie：凭据模式要设为
include，而且服务端必须同时返回Access-Control-Allow-Credentials: true，并且此时Allow-Origin不允许写通配的星号。三个条件缺一个都不行。 - 想改
Cookie、User-Agent、Referer、Host这些头：改不了。它们由浏览器接管，代码里设置会被静默忽略，工具会对这些头给出明确提示。
结论也很清楚：调试自家开放了 CORS 的接口、或本地 localhost 服务时，浏览器内调试最顺手；调第三方没开跨域的接口，就得换命令行或服务端代理，这不是工具能绕过的。
顺带说两个高频参数问题。Query 参数与 URL 是双向同步的，直接在地址里写 ?a=1 会被反向解析成参数列表，改任一侧另一侧跟随，省掉手工拼接时的编码错误。请求体类型选 JSON 时会做语法校验并自动推导 Content-Type，但如果服务端要求的是 application/x-www-form-urlencoded，请老实切到表单类型，很多「参数收不到」就是 Content-Type 与实际体格式不匹配。
二、cURL 转代码时最容易丢掉的东西
从浏览器网络面板「Copy as cURL」拿到的命令，直接翻译成代码是最省事的复现方式。cURL转代码支持约 25 个常用参数，可输出 fetch、axios、Python requests、Java 11+ HttpClient 四种目标。真正需要人工确认的是下面这几处语义落差。
-d与--data-raw的方法推断。带数据参数时默认方法变成POST，如果原始请求是别的方法，-X必须存在。手工删改命令时最容易把-X PUT删掉，代码就悄悄变成了POST。- JSON 体不能当字符串硬塞。Python 侧用
json.loads解析后交给json=参数，才不会把 JSON 的true、null误当成 Python 的True、None；反过来把 Python 字典直接str()出来会得到单引号，服务端解析必然失败。 -b/--cookie与-A/--user-agent在浏览器端会失效。生成的fetch代码里这些头会被浏览器覆盖，工具会以注释标注。要在浏览器环境复现带 Cookie 的请求，只能靠同源加凭据模式，不能靠手写头。-k/--insecure无法在浏览器实现。跳过证书校验是命令行的能力，页面里没有对应开关。自签证书的测试环境只能先在浏览器里手动信任证书。-L跟随重定向的默认值不同。fetch默认就跟随，Pythonrequests也默认跟随，但 Java 的HttpClient默认不跟随，需要显式配置，否则会拿到 302 而不是最终响应。-F表单与手写Content-Type冲突。multipart/form-data的 boundary 由库自动生成，如果你又手工设了Content-Type头，boundary 就对不上，服务端会报解析失败。- 超时不会自动带过去。
-m对应的超时在部分目标语言里需要额外配置，漏掉的后果是线上偶发挂死。
还有一个非技术的坑：命令经过聊天软件转发后，英文引号常被替换成中文引号，解析会直接报错，替换回英文引号即可。
三、WebSocket 调试先看握手，再看保活
WebSocket 的问题几乎都集中在两头：连不上，或者连上一段时间后莫名断开。
握手阶段本质是一次 HTTP 升级请求，服务端返回 101 Switching Protocols 才算成功。用WebSocket在线调试时有两条硬约束要先确认：一是 HTTPS 页面不能连明文的 ws:// 地址，混合内容会被浏览器直接拦截，测试环境也请配 wss://；二是浏览器的 WebSocket API 无法自定义请求头，这意味着鉴权 Token 只能放在查询参数里，或者连接建立后作为第一条消息发送，服务端的鉴权设计必须配合这一点。子协议如果填了，服务端最终选中的那个会显示出来，双方协商不一致也会导致握手失败。
保活阶段的典型现象是「本地测好好的，部署后一分钟就断」。原因通常是网关的空闲超时，Nginx 的 proxy_read_timeout 默认 60 秒，没有数据往来就断连。协议层的 ping/pong 控制帧浏览器不暴露给 JavaScript，所以业务层需要自己定时发一条心跳消息，工具里可以自定义心跳内容与间隔，间隔取网关超时的一半左右比较稳。
断开时最有信息量的是关闭码。1000 是正常关闭，1006 表示异常断开且没有收到关闭帧，浏览器不会告诉你更多——它对应网络中断、代理超时或服务端进程退出，需要结合服务端日志判断。1009 是消息过大，1011 是服务端内部错误。日志区按发送、接收、系统、错误四类着色，带毫秒时间戳与字节数，可以一键复制全部日志，提工单时把这段贴上比描述现象有效得多。二进制消息按十六进制收发，字节数会一并给出，排查协议帧结构时用得上。
最后一句安全提醒：不要在公共回声服务上发真实业务数据或凭据，那些地址会把你发的内容原样回传，但你无法确认它是否也留了一份。
四、User-Agent 能解析出什么，不能用来做什么
UserAgent工具能从 UA 字符串里解析出浏览器与版本、排版引擎、操作系统与版本、设备类型、设备型号、CPU 架构，同时展示屏幕分辨率、设备像素比、语言、时区、CPU 核心数等运行环境信息。这些在复现「只在某个机型或某个内核版本上出问题」的兼容性 bug 时很实用：让用户把解析结果截图发来，比问「你用什么浏览器」得到的信息准确得多。
但 UA 的可靠性有明确上限，这几点必须写进你的判断逻辑里。
- UA 完全由客户端控制。浏览器开发者工具一键就能改，任何脚本也能任意伪造。凡是「根据 UA 判断是不是我们的 App」「根据 UA 拦截爬虫」的逻辑，都只是提高一点噪音门槛，不构成安全边界。真正的身份判断只能靠签名、Token 与服务端会话。
- UA 字符串本身充满历史包装。为兼容旧站点的探测代码，Chrome 的 UA 里同时带着
Mozilla、AppleWebKit、KHTML, like Gecko、Safari几个词，Edge 里还带着Chrome。用「包含某个关键词」来判定浏览器几乎一定误判，解析要按整体结构而不是子串。 - UA 正在被主动削弱。主流浏览器已经在冻结 UA 中的版本与平台细节，改用客户端提示（Client Hints）按需提供。这意味着依赖 UA 精确版本的代码会随时间失效。
- 功能判断请用特性检测。要知道某个 API 能不能用，直接检查该 API 是否存在，而不是先猜浏览器再查表。这是唯一不会随浏览器更新而腐坏的写法。
UA 解析全过程在本地完成，粘贴进去的字符串不会上传，可以放心用用户反馈里的原始 UA 做分析。
常见问题
同一个接口用命令行能调通，在浏览器工具里就失败，是工具有问题吗？ 基本不是。命令行不受同源策略约束，浏览器受。请打开 F12 控制台看确切报错：如果是 CORS 相关，说明目标服务端没为你的来源放行，需要服务端加响应头或改用服务端代理。
为什么加了 Authorization 头之后连请求都没发出？
自定义头触发了预检。浏览器先发 OPTIONS，服务端必须响应并在 Access-Control-Allow-Headers 中包含 authorization，预检不通过时真实请求不会发送，网络面板里只能看到一条 OPTIONS。
转出来的代码跑起来结果和浏览器里不一样？ 优先核对三处：方法是否被数据参数改写、请求体的 Content-Type 与实际格式是否匹配、Cookie 与 UA 这类受限头在目标环境里是否真的生效。生成代码里的注释已经标出了浏览器实现不了的选项。
WebSocket 一直返回 1006，怎么进一步定位？ 先确认地址协议与页面协议匹配、鉴权参数是否在查询串里、服务端日志有没有对应连接记录。如果服务端根本没看到连接，问题在网络或代理层；如果看到连接后主动关闭，就是鉴权或协议校验失败。