UD5工具箱
什么是CORS预检请求？
CORS预检请求（Preflight Request）是浏览器在发送某些跨域请求之前自动发送的一个OPTIONS请求。它的目的是"预先询问"服务器是否允许该跨域请求，以及允许哪些方法和头部。预检请求的工作流程如下：浏览器先构建一个OPTIONS请求，在请求头中添加Origin（当前页面的源）、Access-Control-Request-Method（实际请求要使用的方法）和Access-Control-Request-Headers（实际请求要使用的自定义头列表）。服务器收到预检请求后，在响应中返回CORS相关的头部：Access-Control-Allow-Origin（允许的源）、Access-Control-Allow-Methods（允许的方法）、Access-Control-Allow-Headers（允许的头）。浏览器检查响应中的CORS头部是否允许当前的跨域请求。如果所有检查通过，浏览器再发送实际的请求；如果任何检查失败，浏览器阻止实际请求并在控制台输出CORS错误信息。预检请求会引入额外的网络延迟（一次完整的HTTP往返），因此需要通过Access-Control-Max-Age头缓存预检结果来优化性能。预检请求是W3C CORS规范的一部分，所有现代浏览器都支持。
什么情况会触发预检请求？
触发预检请求的条件包括以下几类。第一类是HTTP方法：使用PUT、DELETE、PATCH、TRACE、CONNECT等非简单方法会触发预检。GET、HEAD和POST属于简单方法，在不满足其他触发条件时不会触发预检。第二类是请求头：使用自定义请求头（如Authorization、X-Requested-With、X-Custom-Header）会触发预检。标准头中，Accept、Accept-Language、Content-Language属于简单头，不会触发预检；而Content-Type只有在值为application/x-www-form-urlencoded、multipart/form-data或text/plain时才属于简单头，值为application/json时会触发预检。第三类是Content-Type：即使使用POST方法，如果Content-Type为application/json、application/xml、text/xml等非简单类型，也会触发预检。第四类是凭据：当请求配置中设置了credentials: 'include'时，在某些浏览器实现中可能触发预检（但W3C规范中credentials本身不触发预检）。第五类是Accept头中的非简单值：如果Accept头包含除*/*外的复杂MIME类型，某些浏览器会触发预检。在实际开发中，最常见的预检触发场景是：POST请求携带JSON数据（Content-Type: application/json）和携带Authorization头的请求。
Access-Control-Allow-Origin可以设置多个值吗？
不可以。Access-Control-Allow-Origin头不支持逗号分隔的多个值。这是W3C CORS规范的明确限制。如果服务器需要允许多个源访问，有以下几种解决方案。方案一：动态匹配。服务器检查请求中的Origin头，如果Origin在允许列表中，就将Access-Control-Allow-Origin设置为该Origin值；如果不在列表中，就不返回Origin头（或返回其他值）。这是最常用的方案，大多数CORS中间件（如Express cors）都支持这种方式。方案二：使用通配符*。如果不需要携带凭证且不需要精确控制源，可以将Allow-Origin设为*表示允许所有源。但*不支持携带凭证（credentials: include）。方案三：服务器端使用逻辑判断。在后端代码中根据请求的Origin动态返回对应的Allow-Origin值。例如在Express中：app.use(cors({ origin: ['https://a.com', 'https://b.com'] }))。方案四：使用反向代理。通过Nginx等反向代理统一处理CORS，避免在每个后端服务中重复配置。在选择方案时，需要根据安全性要求、性能需求和架构复杂度进行权衡。
如何优化CORS预检性能？
优化CORS预检性能的核心方法是使用Access-Control-Max-Age头缓存预检结果。在预检响应中设置Access-Control-Max-Age头（如86400秒=24小时），浏览器在缓存有效期内不会重复发送预检请求，直接使用缓存的结果。不同浏览器对Max-Age的最大值有限制：Firefox最大86400秒，Chrome最大7200秒，Safari约5秒。建议设置为3600秒（1小时）作为通用值。其他优化策略包括：减少自定义头的数量——每增加一个自定义头都可能导致预检，尽量使用简单头或标准头；使用HTTP/2或HTTP/3——多路复用可以减少预检请求的延迟影响；将CORS配置集中在API网关或反向代理层——避免在每个后端服务中重复配置，减少配置不一致的风险；预检请求和实际请求使用相同的TCP连接——确保服务器支持Keep-Alive以复用连接。在性能敏感的场景中，还可以考虑将高频API改为简单请求格式（如使用GET代替POST、使用application/x-www-form-urlencoded代替application/json），从根本上避免预检。但需要注意，这些改动可能影响API的设计和安全性，需要综合权衡。
预检失败的调试步骤是什么？
按照以下步骤系统性地调试CORS预检失败。第一步，打开浏览器开发者工具的Network面板，找到失败的请求（通常是被标红的OPTIONS请求）。第二步，查看请求的预检头：确认Origin、Access-Control-Request-Method和Access-Control-Request-Headers的值是否正确。第三步，查看响应：检查HTTP状态码（应该是200或204），查看所有响应头。第四步，使用本工具复现测试：输入相同的参数，发送预检请求，查看详细的分析结果。第五步，逐项检查CORS头：Allow-Origin是否匹配Origin、Allow-Methods是否包含请求方法、Allow-Headers是否包含自定义头、Allow-Credentials是否正确设置。第六步，检查服务器日志：查看服务器是否收到了OPTIONS请求、服务器是否返回了正确的CORS头、是否有服务器错误（500）。第七步，检查CORS配置代码：确认CORS中间件的配置是否正确、是否在路由之前注册、是否被其他中间件覆盖。第八步，测试不同场景：使用curl在命令行中测试（排除浏览器因素）、使用本工具的cURL命令功能、从不同Origin测试。第九步，如果问题仍然存在，检查是否有代理（如Nginx）或防火墙修改了响应头。
OPTIONS请求返回200和204有什么区别？
HTTP 200 OK和204 No Content在CORS预检响应中的区别主要体现在响应体方面。200状态码表示请求成功，服务器可以返回包含CORS头的响应体（通常是HTML或JSON）。204状态码也表示请求成功，但服务器不返回任何响应体。对于CORS预检请求，两者都是有效的成功响应，浏览器会正常处理。但从规范和实践角度来看，204更适合预检响应，因为预检请求不需要响应体，使用204可以明确表示"无内容"。W3C CORS规范没有强制要求预检响应的状态码，只要状态码在2xx范围内且包含正确的CORS头即可。主流框架的默认行为：Express cors中间件默认返回204；Django corsheaders中间件默认返回200（某些版本）；Spring Boot默认返回200。在调试时，如果预检响应返回了非2xx状态码（如403 Forbidden、405 Method Not Allowed），说明服务器没有正确处理OPTIONS请求。需要检查服务器配置：Web服务器是否支持OPTIONS方法、CORS中间件是否正确注册、路由处理器是否处理了OPTIONS请求。在某些情况下，403可能表示服务器的认证中间件在CORS中间件之前执行，拦截了OPTIONS请求。
Access-Control-Allow-Credentials与*冲突如何解决？
当Access-Control-Allow-Credentials设置为true时，Access-Control-Allow-Origin不能使用通配符*。这是W3C CORS规范的安全要求，原因是：如果服务器允许任何源（*）携带凭证访问，恶意网站可以通过伪造请求获取用户的cookies和认证信息，导致严重的安全漏洞。解决方法是将Access-Control-Allow-Origin设置为具体的Origin值。在后端代码中，需要动态判断请求的Origin：获取请求中的Origin头 -> 检查该Origin是否在允许列表中 -> 如果匹配，将Allow-Origin设置为该Origin值 -> 如果不匹配，不返回CORS头（拒绝请求）。示例代码（Node.js Express）：app.use(cors({ origin: function(origin, callback) { const allowedOrigins = ['https://myapp.com', 'https://admin.myapp.com']; if (!origin || allowedOrigins.includes(origin)) { callback(null, origin); } else { callback(new Error('Not allowed by CORS')); } }, credentials: true }))。在Nginx中，可以使用map指令动态设置Allow-Origin：map $http_origin $cors_origin { default ""; "https://myapp.com" $http_origin; }。确保每个返回CORS响应的端点都使用了动态Origin匹配，而不是静态的*配置。
本工具支持测试哪些类型的CORS场景？
本工具支持测试以下CORS场景。第一，标准的简单请求：GET、HEAD、POST（简单Content-Type），验证基础的CORS配置。第二，预检请求：使用非简单方法（PUT、DELETE、PATCH）或非简单头（Authorization、自定义头）的请求，验证预检流程和CORS头的正确性。第三，携带凭证的请求：验证Allow-Credentials与Allow-Origin的兼容性，确保credentials: include模式下CORS配置正确。第四，自定义Origin：模拟任意来源域名的请求，测试服务器的Origin白名单配置。第五，null Origin：测试来自沙箱iframe或本地文件的请求。第六，多方法测试：支持GET、POST、PUT、DELETE、HEAD、PATCH、OPTIONS七种HTTP方法。第七，cURL命令生成：用于在命令行中绕过浏览器CORS限制进行测试。第八，手动分析模式：在不实际发送请求的情况下验证CORS头的配置正确性。第九，响应头表格：清晰展示所有响应头，区分CORS头和普通头。工具的测试结果基于实际的HTTP请求，反映服务器的真实CORS配置，适合用于开发调试和配置验证。