CORS 响应头生成器
生成静态 CORS 响应头，核对已发生预检的参数
输出是单个静态来源的配置，不会动态回显任意 Origin。多来源服务器应先验证自己的允许列表。null 来源也可能来自沙箱页面或本地文件，应按业务需求决定是否允许。
生成后显示响应头及服务器片段。
服务器片段只设置响应头；请放入正确上下文，并配置 OPTIONS 响应与实际接口。未模拟响应状态、重定向、缓存、私网/本地网络权限或浏览器扩展策略。
从浏览器的 OPTIONS 请求复制 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers。这里假设预检已经发生，不判断普通请求是否需要预检。头列表只填写浏览器列出的非安全头名称。
按 Fetch 规范要求，Authorization 必须显式允许，不能只用 *。部分 Chrome 版本的实测行为不同；本工具保留规范判断，不保证任意浏览器都会得到相同结果。CORS 失败也不代表请求一定未发送。
配置只在浏览器处理，不访问请求来源或保存草稿。
完整说明还包括常见问题处理、操作示例、代码片段、FAQ 和相关工具，便于核对结果或排查问题。
工具说明
CORS 响应头生成器为单个静态来源配置允许方法、请求头、可被脚本读取的响应头、凭据和预检缓存秒数。工具会检查来源格式、标记列表及 Max-Age，并拒绝凭据与通配来源的组合。输出包含 Node/Express 及可表达时的 Nginx 设置响应头语句，但这些语句不会自动实现接口或处理 OPTIONS。独立检查区用于比较从实际浏览器预检复制的参数与生成配置，采用有限的 Fetch 规范模型，区分安全方法和不同凭据模式下的通配符语义。不预测是否需要预检、不动态回显来源、不访问服务器，也不认证实际浏览器一定放行。
生产可用片段
发生预检的 GET 不要求 Allow-Methods 再列出 GET
text
浏览器预检参数：
Origin: https://app.example.com
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-trace
凭据模式：omit
相关响应头：
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Headers: X-Trace
即使自定义头触发预检，GET 仍属于安全方法。本例只检查所填参数，不发送 OPTIONS，也不验证实际服务器响应。推荐工作流
常见问题
工具会实现动态来源回显吗？
不会，输出仅使用单个静态来源。多个来源应先在服务器验证允许列表，再选择响应来源；不要没有策略地照抄任意请求 Origin。
预检检查区应该填什么？
从真实 OPTIONS 请求复制 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers。请求头输入是浏览器生成的非安全头名称列表，不是原请求的全部头。
GET 或 POST 必须列入 Allow-Methods 吗？
GET、HEAD 和 POST 属于 CORS 安全方法。在 Fetch 预检算法中，不要求它们出现在 Allow-Methods；允许的请求头等其他条件仍需满足。
* 能放行 Authorization 或带凭据请求吗？
Fetch 规范要求显式列出 Authorization。credentials: include 下，方法和请求头通配符的语义也会改变，且不能使用通配来源。部分浏览器实现存在差异，本检查保留规范规则。
服务器片段是完整的 CORS 中间件吗？
不是，它们只设置响应头。实际接口、OPTIONS 状态和放置位置仍需配置。值中含 $ 时，Nginx 会把它解释为变量，因此不输出 Nginx 片段。工具把 Max-Age 限制为 0–86400 秒，浏览器还可能采用更低上限。
检查没有覆盖什么？
不测试响应状态、重定向、缓存、Cookie、私网/本地网络权限及浏览器扩展。CORS 失败可能发生在请求已发送之后。工具不访问来源地址，也不保存配置草稿。
继续浏览