对接方接口报错
凌晨两点，上游 ERP 系统推送订单时返回 500 错误。运维怀疑是 Header 里 token 过期，开发怀疑是 Body 字段类型不符。用本工具逐项测试：先只传 token 看 200，再逐字段加 Body 看 400，最终锁定是 'amount' 字段传了字符串而非数字。不用等对方上班抓包，自己十分钟定位问题。
示例
请求头request headers · key / value
请求体request body · JSON / raw（POST / PUT / PATCH / DELETE）
正在发送请求…
经同源服务器代理转发，请稍候
!
请求失败
—
响应头response headers
响应体response body
填写 URL 与方法后点击「发送」测试 HTTP 接口
就绪 · 经同源 API 代理转发，请勿传敏感凭据 / 内网接口
第一节
关于本工具
About调试接口时，最怕的是后端说“我这边正常”，而前端死活连不上。在地址栏输入 URL，选好方法，填上 Header 和 Body，点击发送就能看到原始响应——状态码、响应头、返回体，一个不落。请求由服务端发起，能绕过浏览器的跨域限制，适合用来验证 API 是否真的可达，而非被 CORS 策略挡掉。
使用场景
Webhook 回调验证
支付平台要求配置回调 URL，但文档里只写了 '需返回 200 OK'。用本工具模拟支付平台发 POST 请求，传 JSON 格式的订单 ID 和签名。发现本地服务返回的是 302 重定向而非 200，导致支付平台认为回调失败。调整路由返回 200 后，线上交易流水恢复正常。
CDN 缓存策略排查
用户反馈图片更新后浏览器还是旧图。用本工具分别带 'Cache-Control: no-cache' 和不带该 Header 请求同一 URL，对比响应头里的 'Age' 和 'X-Cache' 字段。发现不带 Header 时 CDN 返回的 Age 值高达 86400 秒，确认是 CDN 缓存 TTL 设置过长。
API 限流阈值试探
供应商接口文档写 '每秒最多 10 次请求'，但实际测试发现第 8 次就开始返回 429。用本工具连续发送 15 次 GET 请求，记录每次返回的状态码和响应时间。发现前 7 次平均 80ms，第 8 次突然跳到 1200ms 并返回 429，确认限流窗口是 1 秒内 7 次。
跨域 CORS 配置验证
前端开发说联调时浏览器报 'No 'Access-Control-Allow-Origin' header'。用本工具发送 OPTIONS 预检请求，带 'Origin: https://myapp.com' 和 'Access-Control-Request-Method: POST'。发现响应头里缺少 'Access-Control-Allow-Headers: Content-Type'，导致 POST 请求被浏览器拦截。
第二节
使用指南
Getting Started使用步骤
- 1在「URL」输入框粘贴目标地址（如 https://api.example.com），支持 http/https 协议
- 2从「Method」下拉菜单选择请求方法（GET/POST/PUT/DELETE 等），默认 GET
- 3展开「Headers」区域，逐行添加键值对（如 Content-Type: application/json），空行自动删除
- 4在「Body」文本框写入请求体（仅 POST/PUT 生效），支持 JSON/XML/纯文本格式
- 5点击「发送」按钮，结果区即时显示状态码、响应头、响应体及请求耗时（ms）
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| URL: https://httpbin.org/get Method: GET Headers: (空) Body: (空) | Status: 200 OK Headers: {"content-type": "application/json", ...} Body: {"args": {}, "headers": {"Host": "httpbin.org", ...}, "origin": "x.x.x.x", "url": "https://httpbin.org/get"} | 常规：最简单的 GET 请求，验证工具能正确发送并接收标准 JSON 响应，适合新手首次测试 |
| URL: https://httpbin.org/post Method: POST Headers: Content-Type: application/json Body: {"name": "test", "value": 123} | Status: 200 OK Headers: {"content-type": "application/json", ...} Body: {"args": {}, "data": "{\"name\": \"test\", \"value\": 123}", "json": {"name": "test", "value": 123}, ...} | 常规：POST 请求带 JSON Body，验证 Body 字段的输入与 Content-Type 头部的配合，返回的 json 字段确认 Body 被正确解析 |
| URL: https://httpbin.org/status/404 Method: GET Headers: (空) Body: (空) | Status: 404 NOT FOUND Headers: {"content-type": "text/html", ...} Body: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <title>404 Not Found</title>... | 边界：非 2xx 状态码，验证工具能正确捕获并显示错误状态码和响应体，而非抛出异常或显示空白 |
| URL: https://httpbin.org/delay/10 Method: GET Headers: (空) Body: (空) | Status: 200 OK Headers: {"content-type": "application/json", ...} Body: {"args": {}, ...} (等待约 10 秒后返回) | 边界：超长延迟请求，暴露工具的超时设置（默认通常 30 秒），若超时则返回错误信息；测试网络稳定性 |
| URL: https://httpbin.org/redirect/5 Method: GET Headers: (空) Body: (空) | Status: 302 FOUND Headers: {"location": "https://httpbin.org/redirect/4", ...} Body: (空) (实际只返回第一个重定向，不自动跟随) | 易错：重定向处理——本工具默认不自动跟随 3xx 跳转，只返回第一个响应；用户需留意 Location 头部手动处理 |
| URL: https://httpbin.org/basic-auth/user/pass Method: GET Headers: Authorization: Basic dXNlcjpwYXNz Body: (空) | Status: 200 OK Headers: {"content-type": "application/json", ...} Body: {"authenticated": true, "user": "user"} | 易错：需要手动构造 Authorization 头部（Base64 编码），验证工具对自定义头部的支持；若头部缺失则返回 401 |
| URL: https://httpbin.org/anything Method: OPTIONS Headers: (空) Body: (空) | Status: 200 OK Headers: {"allow": "GET, POST, PUT, DELETE, OPTIONS, PATCH", ...} Body: {"method": "OPTIONS", ...} | 边界：非 GET/POST 的 HTTP 方法（OPTIONS），验证工具支持所有标准方法，并返回服务端允许的方法列表 |
常见错误对照
1.POST 请求 Body 未设置 Content-Type 导致服务端无法解析
✗ 错误
选择 POST 方法，在 Body 输入 {"name":"test"}，未设置任何 Header✓ 修复
添加 Header：Content-Type: application/json，Body 输入 {"name":"test"}HTTP 规范中，服务端根据 Content-Type 头决定如何解析 Body。缺省时多数服务端按 text/plain 处理，不会自动解析 JSON 或表单数据。
2.URL 中包含未编码的中文或特殊字符
✗ 错误
https://example.com/api?name=张三&age=20✓ 修复
https://example.com/api?name=%E5%BC%A0%E4%B8%89&age=20RFC 3986 规定 URL 只能包含 ASCII 字符。中文、空格、# 等必须 Percent-Encoding 编码，否则服务端可能返回 400 或解析错误。
3.GET 请求带 Body 被服务端忽略
✗ 错误
选择 GET 方法，在 Body 输入查询参数 JSON，期望服务端读取✓ 修复
将参数拼接到 URL 查询字符串：https://example.com/api?key=valueHTTP 规范未禁止 GET 带 Body，但多数 Web 服务器和框架（如 Nginx、Tomcat）会丢弃 GET 请求的 Body，仅解析 URL 参数。
4.Header 值包含换行符导致请求被截断
✗ 错误
Authorization: Bearer token123
X-Custom: value✓ 修复
每个 Header 独占一行：
Authorization: Bearer token123
X-Custom: valueHTTP 头字段以 CRLF 分隔，Header 值内出现换行符会被解析为新 Header 的开始，导致原始 Header 被截断或请求格式错误。
5.JSON Body 末尾多逗号导致解析失败
✗ 错误
{"name":"test","age":20,}✓ 修复
{"name":"test","age":20}RFC 8259 明确禁止 JSON 对象或数组末尾出现逗号。Go 标准库 encoding/json 严格遵循规范，遇到末尾逗号直接返回解析错误。
6.HTTPS 请求忽略证书验证导致连接失败
✗ 错误
请求 https://self-signed.badssl.com/，直接返回证书错误✓ 修复
如果测试自签名证书站点，需在工具中关闭证书验证（若有选项）；否则只请求标准 CA 签发的 HTTPS 站点Go 默认使用系统 CA 证书链验证服务端证书。自签名或过期证书会导致握手失败，返回 x509: certificate is valid for... 错误。
7.Cookie 手动设置时遗漏 Domain 或 Path 属性
✗ 错误
Header 写 Cookie: sessionid=abc123✓ 修复
Header 写 Cookie: sessionid=abc123; Domain=.example.com; Path=/Cookie 的 Domain 和 Path 属性决定了浏览器是否发送该 Cookie。手动测试时若省略，服务端可能因作用域不匹配而拒绝或忽略。
第三节
工作原理
How It Works核心公式
HTTP 响应时间 = T_dns + T_tcp + T_tls + T_request + T_response + T_transfer
变量说明
T_dnsDNS 解析耗时，单位 msT_tcpTCP 三次握手耗时，单位 msT_tlsTLS 握手耗时（HTTPS 时），单位 msT_request发送请求数据耗时，单位 msT_response服务器首字节到达耗时，单位 msT_transfer接收完整响应体耗时，单位 ms
示例
测试 https://api.example.com/data：DNS 解析 12 ms，TCP 握手 28 ms，TLS 握手 45 ms，请求发送 2 ms，首字节到达 87 ms，响应体下载 34 ms。总耗时 = 12+28+45+2+87+34 = 208 ms。
用户输入
后端处理
网络交互
第五节
常见问题
Q & A问为什么我发 POST 请求，返回说“Body 为空”或“400 Bad Request”？＋
答
最常见原因是 Content-Type 没设对。如果你在 Body 里填了 JSON 字符串（如 {"key":"value"}），Header 里必须加 Content-Type: application/json，否则服务端没法解析。另一种情况是 Body 里啥都没填但选了 POST 方法——POST 请求通常需要带数据。本工具不会自动补 Header，需要手动加。如果 Body 是纯文本，用 text/plain；如果是表单格式，用 application/x-www-form-urlencoded。
问测试接口时返回状态码 302，但工具没跳转，是出问题了吗？＋
答
不是问题。本工具默认不跟随重定向，只返回当前请求的原始响应。302 表示服务端让你去另一个地址，但工具把控制权交给你——你能看到 Location 响应头里写了具体要跳去哪。如果你需要测试跳转后的结果，手动把 URL 改成那个 Location 地址再发一次。这样比自动跳转更透明，方便排查跳转链。
问为什么我请求的接口返回了 CORS 错误，这个工具能绕过吗？＋
答
不能，而且也不需要。CORS 错误是浏览器端的安全限制，本工具是后端（Go）直接发请求，不经过浏览器，所以根本不会触发 CORS 检查。如果工具返回了错误信息，那是服务端返回的真实错误（如 403 或 500），跟 CORS 无关。你在浏览器里遇到 CORS 报错时，用本工具发同样的请求，能看到服务端到底回了什么，方便区分是服务端问题还是前端跨域限制。
问我填了 Header 里的 Cookie，为什么服务端说没收到？＋
答
检查 Header 的写法格式。Cookie 的值必须是 key=value 的形式，多个 cookie 用分号加空格隔开（如 session=abc123; token=xyz）。如果直接贴了浏览器里复制的一整段（带 Domain/Path/Expires 等属性），服务端会解析失败。本工具只把 Header 原样发出去，不帮你清洗格式。建议只保留 name=value 部分，去掉其他属性。
问为什么同样的 URL，用这个工具和用 curl 结果不一样？＋
答
大概率是 Header 差异。curl 默认会带一些隐式 Header（如 User-Agent: curl/8.x），而本工具默认只发必要的 HTTP 头（如 Host、Connection）。如果服务端根据 User-Agent 返回不同内容（比如防爬虫或做移动端适配），结果就不一样。可以在本工具里手动加上 curl 的那些 Header 再试一次。反之，如果 curl 带了 Cookie 文件或默认的 Accept-Encoding，本工具没带，也可能导致差异。
问我测一个接口，返回的响应时间每次都不一样，哪个是准的？＋
答
网络波动下响应时间有几十到几百毫秒的偏差是正常的。本工具显示的耗时是服务端从收到请求到返回完整响应的总时间（含网络延迟），不是服务端内部处理时间。如果想测服务端性能，建议发多次取中位数或最小值，避开网络抖动。如果某次特别慢（比如 10 秒以上），可能是服务端有慢查询或限流，跟工具无关。
问我想测试一个需要登录的接口，怎么传登录态？＋
答
两种方式。一是在 Header 里直接加 Cookie 字段，把浏览器登录后的 Cookie 字符串贴进去（注意只保留 key=value 部分）。二是如果接口用 Bearer Token 鉴权，在 Header 里加 Authorization: Bearer <token>。本工具不会保存这些敏感信息，每次请求都是独立的。注意 Cookie 或 Token 有有效期，过期了需要重新获取。
问为什么有些接口返回的响应体是乱码？＋
答
乱码通常是编码不匹配。本工具按 UTF-8 解码响应体，如果服务端返回的是 GBK、Shift_JIS 等其他编码，就会显示乱码。可以先看响应头里的 Content-Type 字段，里面会写 charset（如 charset=gbk）。目前本工具不支持自动转码，建议用其他工具（如浏览器开发者工具）查看原始字节，或手动把响应复制到支持多编码的文本编辑器里查看。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。