跳到正文

CORS 跨域检测

CORS Tester

从你指定的来源发出浏览器会发的预检请求,再带上同一个 Origin 发一次 GET,并按 Fetch 标准的规则说清究竟是哪个响应头把它挡住了。

控制台里的 CORS 失败会点出缺的是哪个响应头,却几乎从不说原因,而浏览器实际发出的请求也不是你代码里写的那个。这里从你选定的源发出浏览器会发的预检请求,再发一个带着该 Origin 的 GET,然后按 Fetch 标准的规则解读结果。

☁️ 使用我们的服务器corshttpdebugweb

这个请求由我们的服务器代你发出。送到服务器的只有你输入的网址、页面来源、方法和头字段名,你的 Cookie 和登录状态都不会跟着走。服务器只连接公网地址,私有地址和内网地址一律拒绝。

由服务器代你发出浏览器会发的预检(OPTIONS)和真正的请求,再按 Fetch 标准的 CORS 规则来判。真正的请求永远是 GET(或 HEAD)——不会替你往别人的 API 上打 PUT 或 DELETE。

发起调用的那个网页的协议、主机和端口。

application/json 一定会触发预检。

怎么用

  1. 输入 URL 和源

    源是请求“从哪里发出”的那个站点——发起调用的页面,不是 API。把这两个填反,是测试结果和浏览器不一致最常见的原因。

  2. 加上你真正使用的方法和请求头

    预检只在非简单请求时发生。触发它的是 `Content-Type: application/json` 或者 `Authorization` 头,所以漏掉它们,测的就是一个你从来不会发的请求。

  3. 读是哪条规则失败了

    结果点出具体是哪项检查——源不被允许、方法未列出、请求头未列出、凭据配上了通配符源——而不是报一个笼统的失败。

常见问题

这里通过了,浏览器还是拦着。

确认方法、请求头和凭据模式和你代码发出的完全一致,并且服务器不会按 cookie 或 user agent 改变响应。这里是从服务器上发起的,所以一个依赖于你手上某个会话的响应,会和这里不一样。

为什么 `Access-Control-Allow-Origin: *` 配 cookie 不行?

标准禁止这样。用 `credentials: 'include'` 时,源必须原样回显,并且必须有 `Access-Control-Allow-Credentials: true`。通配符加凭据被拒绝是设计如此,不是 bug。

这是在我的浏览器里运行的吗?

不是——它从服务器上运行,因为浏览器发不出那个被 CORS 拦下的请求。这意味着它看到的是公开的响应,没有你的 cookie,也没有你的网络位置。

能测内网地址吗?

不能。请求从一台到不了你网络的服务器发出,只在你网络内部才能解析的地址,不管 CORS 配得怎样都会失败。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。