CORS Denetleyici
CORS Tanı Paneli
Allow-Origin, Allow-Headers veya credentials ile ilgili sorunları hızlıca belirlemek için preflight ve gerçek istekleri sunucu tarafında simüle edin.
Sunucu tarafında gerçek CORS preflight ve gerçek istek simülasyonu, 6 yanıt başlığı adım adım kontrol edilir, çapraz kaynak yapılandırma hataları hassas şekilde konumlandırılır ve Nginx/Node.js/Spring dahil birden fazla framework için düzeltme kodu sağlanır.
İlgili Öneriler
Kullanım senaryoları
- 浏览器控制台出现No 'Access-Control-Allow-Origin' header报错时，第一时间用本工具检测目标接口实际返回的CORS头
- 前后端分离项目联调阶段，验证后端CORS配置是否正确生效，避免盲目改配置浪费时间
- 配置Nginx、Apache反向代理或API网关（Kong/APISIX/Spring Cloud Gateway）后，验证CORS规则是否正确透传
- 携带Cookie的跨域请求失败时，切换credentials模式检测Allow-Credentials和Allow-Origin的配置冲突
- 添加自定义请求头（如X-Token、X-Requested-With）后请求被拦截，检测是否在Allow-Headers中正确声明
- PUT/DELETE/PATCH等非简单方法请求跨域失败，检查Allow-Methods是否包含对应方法
- 前端无法读取自定义响应头（如X-Request-Id、X-Total-Count），检测Access-Control-Expose-Headers配置
- CDN加速后跨域时好时坏，检测Vary: Origin是否正确设置避免CDN缓存错误响应
- 生产环境偶发跨域错误，复现问题场景并保留完整响应报文供后端排查
- 学习CORS原理时，通过实际请求观察各响应头的作用，加深对跨域机制的理解
Nasıl Kullanılır
- 在目标URL输入框中填写需要检测的接口完整地址（支持http/https，需包含路径）
- 在请求源Origin处填写你的前端页面实际来源（如https://example.com，注意要包含协议和端口，不要带路径）
- 选择HTTP请求方法（GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS），默认GET
- 在自定义请求头区域添加你需要发送的头部，每行一个格式如X-Token: abc123，Content-Type如果是application/json等非简单类型会自动触发预检
- 根据你的场景勾选「携带凭证（credentials）」选项，如果前端代码用了withCredentials=true或fetch的credentials: 'include'必须勾选
- 点击「开始检查」按钮，工具会在服务端依次发送OPTIONS预检请求和实际请求（如果预检通过或不需要预检）
- 查看分析报告：先看整体评估结果，再逐项检查各CORS头状态，根据红色错误项的修复建议调整服务端配置，修复后重新检测验证
Özellikler
- 服务端真实模拟预检请求与实际请求，不受浏览器缓存和插件干扰，结果更准确
- 分离展示OPTIONS预检响应和实际GET/POST响应，清晰区分哪一环节出现问题
- 逐项检查6大核心CORS响应头：Access-Control-Allow-Origin、Allow-Methods、Allow-Headers、Allow-Credentials、Expose-Headers、Max-Age，每个头单独标注通过/警告/失败状态
- 智能检测通配符*与credentials凭证模式的经典冲突，第一时间提示这个最常见的配置陷阱
- 支持自定义请求源Origin、HTTP方法（GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS）、任意自定义请求头
- 可切换是否携带凭证（Cookie/Authorization头/TLS客户端证书）模式，模拟withCredentials=true场景
- 自动检测Vary: Origin响应头是否正确设置，避免CDN/反向代理缓存错误的CORS响应
- 结构化展示预检缓存Max-Age配置，评估预检请求频率对性能的影响
- 检查Access-Control-Expose-Headers配置，确认哪些响应头可以被前端JavaScript读取
- 提供逐行修复建议，包含Nginx、Apache、Node.js/Express、Spring Boot、Python/Django/Flask等主流服务端框架配置示例
- 完整记录请求响应原始报文，包括状态码、所有响应头、响应体预览，便于深度排查
- 自动识别简单请求与需预检请求的差异，解释为什么你的请求触发了OPTIONS预检
- 检测重定向场景下的CORS问题（301/302/307/308跳转后Origin是否变化）
- 支持HTTPS/HTTP混合内容场景检测，提示混合内容导致的跨域相关问题
Sık Sorulan Sorular
为什么用Postman/curl请求接口没问题，浏览器一访问就报跨域错误？
这是最经典的CORS问题！因为Postman和curl根本不受浏览器同源策略限制——它们是HTTP客户端，不是浏览器，不会拦截响应，也不会自动发OPTIONS预检请求。跨域错误是浏览器独有的安全机制，只有浏览器的JavaScript运行环境才会执行CORS检查。Postman能调通只能证明接口本身能返回数据，不能证明CORS配置正确。你需要用浏览器、或者本工具（服务端模拟浏览器CORS流程）来检测，才会发现问题。
CORS错误是前端问题还是后端问题？应该谁来修？
99%的CORS错误是后端配置问题（或者Nginx/网关层配置问题），前端能做的非常有限。CORS的核心是服务器通过响应头「授权」浏览器允许跨域访问，前端只能设置withCredentials、设置请求头这些，无法绕过浏览器的安全限制。网上说的前端用代理（devServer proxy、Nginx反向代理把前端和接口代理到同个源）本质是「欺骗」浏览器让它以为是同源请求，不是真的解决了CORS问题，生产环境如果前后端不同源还是需要后端正确配置CORS。
为什么我的GET请求不跨域，一改成POST/PUT就跨域了？
因为GET通常满足简单请求条件，浏览器直接发请求；而POST如果你发的是Content-Type: application/json（90%的POST接口都是这个），就不属于简单请求了，会触发OPTIONS预检。预检请求需要服务器返回正确的CORS头，很多人只给GET/POST配了CORS头但没处理OPTIONS方法，或者OPTIONS响应没带头，就报错了。PUT/DELETE/PATCH这些方法本身就不是简单方法，必然触发预检。
开发环境怎么解决跨域？生产环境呢？
开发环境有几种方案：①框架自带的代理（Vue CLI的devServer.proxy、Vite的server.proxy、Create React App的proxy）：把接口请求代理到前端开发服务器同源，浏览器以为是同源请求不跨域；②关闭浏览器安全参数（比如Chrome加--disable-web-security启动参数），仅限本地临时测试，绝对不能用于正常浏览；③后端配置CORS允许localhost源（推荐，和生产环境行为一致）。生产环境必须后端正确配置CORS：配置允许的源白名单、正确设置Allow-Methods/Allow-Headers/Allow-Credentials、加Vary: Origin，或者用网关/Nginx统一处理CORS。
Access-Control-Allow-Origin可以配置多个源吗？怎么配置多个域名允许跨域？
不行，Access-Control-Allow-Origin响应头只能有一个值，要么是具体的一个源（如https://a.com），要么是*。浏览器不接受多个源（比如写https://a.com,https://b.com是无效的，浏览器会认为不匹配）。正确的多源配置方式是：服务器维护一个允许的源白名单列表，每次收到请求时读取请求头中的Origin值，检查这个Origin是否在白名单中，如果在就把Access-Control-Allow-Origin设置为这个具体的Origin值，同时返回Vary: Origin头；如果不在就不返回CORS头或者返回错误。不要试图返回多个Allow-Origin头或者用逗号分隔多个值，浏览器都不认。
预检OPTIONS请求需要返回业务逻辑吗？可以直接返回204吗？
OPTIONS预检请求不需要返回任何业务逻辑和响应体，只需要返回正确的CORS响应头和200/204状态码就可以了。浏览器收到正确的CORS头就认为预检通过，不会读取OPTIONS响应的body内容。所以最佳实践是：在Nginx/网关层直接拦截OPTIONS请求，返回204 No Content和正确的CORS头，不转发到后端应用服务器，这样既减轻后端压力，也避免后端路由不支持OPTIONS导致的405错误。但要注意确保OPTIONS响应的CORS头和实际请求的CORS头保持一致。
为什么我设置了withCredentials: true，Cookie还是没带上？
带Cookie的跨域请求需要同时满足三个条件：①前端XMLHttpRequest.withCredentials = true或者fetch的credentials: 'include'；②后端响应头Access-Control-Allow-Credentials: true；③Access-Control-Allow-Origin不能是*，必须是具体源。三个条件缺一不可。另外还要注意Cookie的属性：Cookie必须设置了SameSite=None; Secure（HTTPS环境）才能在跨域请求中携带；如果Cookie是SameSite=Lax或Strict，跨域请求不会带；Cookie的Domain属性要正确设置；还要注意第三方Cookie政策的影响（Chrome等浏览器对第三方Cookie有限制）。
CORS和CSRF是什么关系？配置CORS会导致CSRF漏洞吗？
CORS是放宽跨域访问限制，CSRF是跨站请求伪造攻击，两者是不同概念。正确配置CORS不会直接导致CSRF漏洞——因为CORS只是允许JS读取响应，而CSRF是攻击者诱导用户在不知情的情况下发送请求（比如img标签、自动提交表单），这些请求即使没有CORS也会发出去带上Cookie。防御CSRF需要用CSRF Token、SameSite Cookie、验证Origin/Referer等方案，不能靠禁用CORS来防CSRF。但如果你配置CORS时把Allow-Origin设为*且允许带凭证，确实会放大CSRF风险，所以带凭证场景绝对不能用*，必须严格限制白名单源。
文件下载、重定向、图片/script标签加载会有CORS问题吗？
普通的<img>、<script>、<link>标签加载跨域资源（CDN图片、JS脚本、CSS）默认不会有CORS问题，这些是「嵌入资源」不是「AJAX请求」，浏览器允许加载但JS不能读取内容。但如果你想在Canvas中操作跨域图片、或者用fetch/XHR加载这些资源并读取内容，就需要CORS，同时标签上要加crossorigin属性。跨域文件下载（a标签点击下载）默认也不需要CORS。重定向会影响CORS：预检OPTIONS请求如果返回3xx重定向，浏览器会直接拒绝（Preflight redirect is not allowed）；实际请求的重定向如果是跨源的，需要每一跳都正确返回CORS头。
Nginx怎么正确配置CORS？给个可用的配置示例？
Nginx推荐配置要点：①用map指令匹配Origin白名单，动态设置$cors_origin变量；②OPTIONS请求直接返回204不转发后端；③add_header记得加always参数确保错误响应也带头；④加上Vary: Origin；⑤正确配置Allow-Methods/Allow-Headers/Credentials。示例配置可以在本工具检测结果的修复建议中找到，针对Nginx、Apache、Node.js Express、Spring Boot、Python Flask/Django、Koa、Go Gin等主流框架我们都提供了经过验证的配置片段。
CORS配置好之后怎么验证是否生效？
验证CORS的几个步骤：①先用本工具在线检测，输入URL、Origin、方法、头、凭证选项，看预检和实际请求的各项检查是否通过；②打开浏览器DevTools的Network面板，勾选Disable cache禁用缓存（避免旧缓存干扰），触发跨域请求，检查OPTIONS预检和实际请求的响应头是否正确；③在Console看有没有CORS相关错误；④测试不同场景：不带自定义头的GET请求、带application/json的POST请求、PUT/DELETE方法、带Cookie/不带Cookie、带自定义头；⑤用curl模拟OPTIONS请求：curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint，检查响应头是否正确。
为什么跨域请求在Chrome报错，在Safari/Firefox正常？或者反过来？
不同浏览器对CORS规范的实现细节有差异：①Safari对预检缓存Max-Age限制更严格（早期版本只有600秒），Cookie策略（ITP智能反跟踪）也更严格，可能导致跨域Cookie问题；②Chrome对带凭证时的通配符检查更严格，Allow-Headers/Allow-Methods也不允许*，Firefox某些版本可能宽松些；③旧版IE（IE11）用的是XDomainRequest而不是标准XMLHttpRequest，CORS实现有很多坑（比如不支持自定义头、只支持GET/POST）；④不同浏览器对Vary头的处理、重定向处理、安全头的处理有细微差异。解决方法是严格按照CORS规范配置，不要依赖某一个浏览器的兼容行为。
Access-Control-Max-Age设置多少合适？设太长或太短有什么问题？
建议设置为3600（1小时）到86400（24小时）之间。设置太短（比如60秒）：预检缓存很快过期，频繁发送OPTIONS请求，增加请求耗时和服务器压力，在移动弱网环境下影响明显。设置太长（比如31536000即一年）：如果你更新了CORS配置（比如新增了允许的方法、头），用户浏览器缓存的旧预检结果可能要很久才过期，期间会出现配置不生效的问题。另外Chrome和Firefox会自动把超过86400秒的值截到86400秒，你设再长也没用。开发环境可以设置为-1禁用预检缓存，方便调试。
WebSocket连接有跨域问题吗？CORS适用于WebSocket吗？
WebSocket（ws://和wss://）不受HTTP CORS机制限制，因为WebSocket是独立的协议，不是HTTP AJAX请求。但WebSocket握手阶段是HTTP请求，服务器可以检查Origin头来决定是否允许连接——这是WebSocket层面的权限控制，不是标准CORS，但原理类似。如果WebSocket连接被拒绝，你需要检查WebSocket服务端的Origin校验配置，而不是HTTP CORS头。Socket.IO等库可能有自己的跨域配置方式，和标准CORS配置类似但不完全一样。另外，HTTP/2 Server Push、WebRTC等其他浏览器API也有各自的权限控制，不完全遵循HTTP CORS。
本工具的检测结果和浏览器行为一致吗？为什么用工具检测通过了浏览器还是报错？
本工具在服务端严格按照W3C CORS规范模拟浏览器的预检和实际请求流程，对CORS头的检查逻辑和现代浏览器基本一致。如果工具检测通过但浏览器还是报错，可能的原因：①浏览器缓存了旧的预检结果或响应，按Ctrl+F5强制刷新或者清除缓存再试；②浏览器扩展（广告拦截、隐私保护、安全插件）修改或拦截了请求；③你在工具中填写的Origin、请求头、方法、凭证选项和实际前端发送的不一致（比如前端实际还带了某个自定义头但你没在工具里加）；④CDN/代理节点缓存不一致，工具请求的节点和浏览器请求的节点返回不同结果；⑤浏览器有特殊安全策略（比如HTTPS页面请求HTTP混合内容被拦截、本地文件file://协议的特殊限制）。
Sorun Giderme
浏览器控制台报 No 'Access-Control-Allow-Origin' header 错误，但用curl/postman请求能看到响应头
服务器对OPTIONS方法没配置CORS头：curl发的是GET/POST能看到头，但浏览器先发OPTIONS预检，OPTIONS响应没带头 服务器返回4xx/5xx错误时没带CORS头：Nginx的add_header默认只对2xx和部分3xx生效，错误响应需要加always参数 请求被WAF/防火墙/安全插件拦截了OPTIONS方法，拦截响应没有CORS头 CDN缓存了旧的不带CORS头的响应（缺少Vary: Origin导致的缓存污染） 浏览器扩展（如广告拦截器、隐私保护插件）修改或拦截了跨域请求头
配置了Access-Control-Allow-Origin: *，但带Cookie的请求还是报错
这是CORS规范的强制限制：只要请求带凭证（withCredentials: true、Cookie、HTTP认证），Allow-Origin绝对不能是通配符* 即使前端没显式设置withCredentials，如果目标域和当前域有Cookie，浏览器可能自动带上 不仅Allow-Origin不能是*，Allow-Headers和Allow-Methods在某些浏览器带凭证时也不能用* 需要同时设置Access-Control-Allow-Credentials: true，并且Allow-Origin返回具体的请求源而非*
预检OPTIONS请求返回405 Method Not Allowed或404 Not Found
后端框架路由只配置了GET/POST等业务方法，没有处理OPTIONS方法的路由 Nginx配置中try_files指令拦截了OPTIONS请求，直接返回404没转发到后端 API网关或安全组配置拦截了OPTIONS方法，认为是"无用"方法 Spring Boot等框架如果没有开启CORS支持，会自动拒绝OPTIONS请求返回403 RESTful API设计中没有为OPTIONS请求单独配置handler
POST application/json请求一直报头不允许，但Content-Type已经加在Allow-Headers里了
拼写错误：Content-Type大小写、横杠写错（比如写成ContentType、Content-type虽然规范不区分大小写但有些严格匹配的服务器会有问题） 只在GET/POST的响应里加了头，但OPTIONS预检响应没加，浏览器看的是OPTIONS的头 Allow-Headers里列的头不全：比如前端还发了X-Requested-With或者其他自定义头没列 值有多余空格：比如写成了"Content-Type, Authorization"（逗号后有空格是可以的，但某些老浏览器解析有问题） Access-Control-Allow-Headers只返回了预检请求中问的头，而不是所有支持的头（虽然规范允许，但某些场景下会出问题）
跨域配置本地测试正常，部署到CDN/Nginx后时好时坏随机出错
缺少Vary: Origin响应头！CDN按URL缓存，第一个请求的CORS头被缓存，后续不同Origin的请求拿到错误的缓存响应 CDN配置了缓存规则，把OPTIONS预检响应也缓存了，后端更新CORS配置后CDN还是旧缓存 Nginx配置了多层add_header，下层的CORS头被上层覆盖或者合并出错 CDN的HTTP头优化功能自动删除或覆盖了Access-Control-*头 HTTPS/HTTP混合内容：页面是HTTPS但接口是HTTP，浏览器直接拦截，看起来像CORS错误 CDN节点配置不一致，部分节点有CORS头部分节点没有
前端能拿到响应状态码和数据，但读不到自定义响应头（如X-Total-Count）
没有配置Access-Control-Expose-Headers响应头！CORS规范默认只暴露少数几个基本响应头给JS读取 默认可访问的响应头只有：Cache-Control、Content-Language、Content-Length、Content-Type、Expires、Last-Modified、Pragma 自定义响应头（X-Request-Id、X-Total-Count、Authorization、Set-Cookie等）必须在Expose-Headers中列出 Set-Cookie和Set-Cookie2永远不会被暴露给前端JS，这是浏览器安全限制，不管怎么配置 即使在Expose-Headers里列了，Set-Cookie也无法通过getResponseHeader读取，浏览器会自动过滤
Sözlük
- CORS (Cross-Origin Resource Sharing)
- 跨域资源共享，W3C标准，通过新增HTTP头字段让服务器声明允许哪些源访问资源，是现代浏览器解决跨域问题的官方方案。
- 同源策略 (Same-Origin Policy)
- 浏览器核心安全机制，只有协议、域名、端口三者完全相同才视为同源，不同源的JavaScript默认无法读取对方资源。
- 预检请求 (Preflight Request)
- 浏览器对非简单跨域请求自动先发的OPTIONS方法请求，用于询问服务器是否允许后续实际请求，预检通过后才发真正请求。
- 简单请求 (Simple Request)
- 满足特定条件（GET/HEAD/POST方法、仅安全头、特定Content-Type）的跨域请求，不需要发预检，直接发送实际请求。
- Access-Control-Allow-Origin (ACAO)
- CORS核心响应头，指定允许访问资源的源，可以是具体源URI或通配符*，带凭证时不能用*。
- Access-Control-Allow-Methods (ACAM)
- 预检响应头，列出服务器支持的所有HTTP方法，多个方法用逗号分隔。
- Access-Control-Allow-Headers (ACAH)
- 预检响应头，列出服务器允许的所有请求头字段，前端发送自定义头必须在此声明。
- Access-Control-Allow-Credentials (ACAC)
- 响应头，布尔值true表示允许跨域请求携带Cookie、Authorization等凭证，此时Allow-Origin不能为*。
- Access-Control-Max-Age (ACMA)
- 预检响应头，指定预检结果缓存时间（秒），合理设置可减少OPTIONS请求提升性能。
- Vary: Origin
- 响应头，告诉CDN/代理该响应内容随Origin变化，缓存时需将Origin作为缓存键，避免跨域响应缓存错乱。
- CORS安全列出的请求头 (CORS-safelisted request headers)
- 不需要在Allow-Headers中声明就可以发送的请求头，包括Accept、Accept-Language、Content-Language、Content-Type（特定值）等。
- 禁止的请求头名 (Forbidden header name)
- 浏览器禁止JavaScript通过编程方式设置的请求头，比如Host、Connection、Cookie、Origin等，这些头由浏览器自动控制。
- 凭证请求 (Credentialed Request)
- 携带Cookie、HTTP认证信息、TLS客户端证书等身份凭证的跨域请求，需要前后端配合设置withCredentials和Allow-Credentials。
- Access-Control-Expose-Headers
- 响应头，列出前端JavaScript可以访问的响应头，默认只有少数基本头可访问，自定义响应头必须在此声明。
- OPTIONS 方法
- HTTP方法之一，用于获取服务器支持的通信选项，CORS用它来发送预检请求，询问服务器允许的方法、头、凭证等。
- Origin 请求头
- 浏览器自动添加的请求头，指示当前请求来自哪个源（协议+域名+端口），服务器根据这个头判断是否允许跨域。
- crossorigin 属性
- HTML元素（如script、img、link）的属性，用于指定是否启用CORS加载资源，值有anonymous（不带凭证）和use-credentials（带凭证）。
- no-cors 请求模式
- fetch API的一种mode，允许发跨域请求但只能发送简单请求且JavaScript无法读取响应内容，相当于发送了一个不透明的请求（Opaque Response）。
CORS Yanıt Başlıkları Tam Referans Tablosu
| Yanıt Başlığı | Amaç | Örnek Değer | Dikkat Edilecek Hususlar |
|---|---|---|---|
Access-Control-Allow-Origin | Çapraz kaynak erişimine izin verilen kaynağı belirtir | https://example.com veya * | Kimlik bilgileri ile birlikte kullanıldığında * kesinlikle kullanılamaz; somut bir Origin döndürülmelidir; dinamik döndürme durumunda Vary: Origin eklenmelidir |
Access-Control-Allow-Methods | Sunucunun desteklediği tüm HTTP yöntemlerini listeler | GET, POST, PUT, DELETE, PATCH, OPTIONS | Preflight yanıtı için zorunludur; yalnızca mevcut istek yöntemini değil, tüm yöntemleri listelemelidir |
Access-Control-Allow-Headers | İzin verilen tüm istek başlığı alanlarını listeler | Content-Type, Authorization, X-Token | Preflight isteğinde Access-Control-Request-Headers olduğunda zorunludur; özel başlıklar dahil edilmelidir; kimlik bilgileri ile birlikte kullanıldığında bazı tarayıcılar * izin vermez |
Access-Control-Allow-Credentials | Çerez vb. kimlik bilgilerinin taşınmasına izin verilip verilmediği | true | Yalnızca küçük harfli true olabilir, 1 veya True olamaz; true olarak ayarlandığında Allow-Origin * olamaz |
Access-Control-Expose-Headers | JS'nin okuyabileceği yanıt başlıklarını listeler | X-Request-Id, X-Total-Count | Varsayılan olarak yalnızca Cache-Control/Content-Language/Content-Type/Expires/Last-Modified/Pragma okunabilir, özel başlıklar burada listelenmelidir |
Access-Control-Max-Age | Preflight sonucu önbellek süresi (saniye) | 3600 | Chrome/Firefox üst sınırı 86400 saniye (2 saat), Safari daha kısa; -1 değeri önbelleği devre dışı bırakır ve her seferinde preflight gönderir |
Vary | CDN/proxy'ye yanıt içeriğinin hangi istek başlıklarına göre değiştiğini söyler | Origin | Allow-Origin dinamik olarak döndürüldüğünde Vary: Origin eklenmelidir, aksi takdirde CDN önbelleği çapraz kaynak sorunlarına neden olabilir |
Access-Control-Request-Method | Sunucuya gerçek isteğin hangi yöntemi kullandığını bildiren preflight istek başlığı | PUT | Tarayıcı tarafından OPTIONS isteğinde otomatik olarak gönderilir, ön uç tarafından manuel olarak ayarlanmaya gerek yoktur |
Access-Control-Request-Headers | Sunucuya gerçek istekte hangi başlıkların taşınacağını bildiren preflight istek başlığı | content-type, x-token | Tarayıcı tarafından OPTIONS isteğinde otomatik olarak gönderilir, birden fazla başlık virgülle ayrılır |
Hangi İsteklerin Preflight (Ön Kontrol) Tetikleyeceğini Belirleme Tablosu
| Tetikleme Koşulu | Preflight Tetikler mi? | Detaylı Açıklama |
|---|---|---|
| İstek yöntemi GET/HEAD/POST dışındaki yöntemlerdir (PUT/DELETE/PATCH/CONNECT/OPTIONS/TRACE) | Evet | Bu üç yöntem dışındaysa, özel başlık olmasa bile preflight tetiklenir |
| Content-Type, text/plain, multipart/form-data, application/x-www-form-urlencoded değil | Evet | En yaygın olanı application/json preflight tetikler! Birçok kişi bu tuzağa düşer |
| İstek özel başlıklar içerir (CORS güvenli listesi dışındaki başlıklar) | Evet | Örneğin X-Token, X-Requested-With, Authorization, X-Custom-Header vb. hepsi tetikler |
| İsteğin gövdesi olarak ReadableStream kullanılmıştır (yükleme akışı) | Evet | Modern tarayıcılarda eklenen akış yükleme API'sı preflight tetikler |
| XMLHttpRequest.upload için olay dinleyicisi kaydedilmiştir (yükleme ilerlemesini dinleme) | Evet | xhr.upload.onprogress kullanıldığında preflight tetiklenir |
| İstek yöntemi GET/HEAD/POST, Content-Type üç basit türden biri, özel başlık yok | Hayır | Bu basit istek kategorisine girer, doğrudan gönderilir, OPTIONS gönderilmez |
| fetch mode: 'no-cors' olarak ayarlandı | Hayır (ancak yanıt opak) | Bu modda JS yanıtı okuyamaz, yalnızca basit istekler gönderebilir |
| fetch credentials: 'include' olarak ayarlandı ancak diğerleri basit istek koşulları | Belirsiz | credentials doğrudan preflight tetiklemez, ancak yalnızca diğer tetikleme koşullarıyla birlikte tetikler; kimlik bilgileri ile CORS doğrulaması daha katı olduğuna dikkat edin |
| Aynı URL daha önce preflight yapıldı ve Max-Age önbellek süresi içinde | Hayır (önbellek isabetli) | Önbellek süresi içinde OPTIONS tekrarlanmaz, önbellek devre dışı bırakılmadıkça veya süresi dolmadıkça |
yaygın CORS Hataları ve Çözümleri Hızlı Referans Tablosu
| Konsol Hata Mesajı | Kök Neden | Çözüm |
|---|---|---|
No 'Access-Control-Allow-Origin' header is present | Yanıtta hiç CORS başlığı yok; sunucu CORS yapılandırılmamış; ağ geçidi/proxy başlıkları yemiş; 500/404 gibi hata yanıtlarında başlık yok | Sunucu tarafı CORS yapılandırmasını kontrol edin; Nginx add_header'a always eklenip eklenmediğini kontrol edin; OPTIONS isteğinin 2xx ve CORS başlıklarıyla döndüğünü doğrulayın |
Allow-Origin value 'XXX' does not match supplied origin | Allow-Origin yapılandırılan kaynak ve gerçek istek kaynağı eşleşmiyor; yapılandırma hatası (eğik çizgi fazlalığı/bağlantı noktası hatası/http/https karışıklığı) | Origin beyaz listesinin istek kaynağını içerip içermediğini kontrol edin; sonundaki eğik çizgi olmadığını doğrulayın; www ve www olmayan farklı kaynaklardır; doğru Origin'i dinamik olarak döndürün |
Preflight response didn't pass access control check: status is not ok | OPTIONS isteği 404/405/500 gibi 2xx olmayan durum kodu döndü; sunucu yönlendirmesi OPTIONS yöntemini işlemiyor; Nginx try_files OPTIONS'ı engelliyor | OPTIONS isteğinin 200/204 döndüğünden emin olun; sunucu/ağ geçidi katmanında OPTIONS yanıtını yapılandırın; Nginx yapılandırmasının OPTIONS'ı doğru işlediğini kontrol edin |
Method XXX is not allowed by Access-Control-Allow-Methods | Preflight yanıtındaki Allow-Methods, kullanmak istediğiniz HTTP yöntemini içermiyor (örn. PUT listelenmemiş) | Access-Control-Allow-Methods'te desteklenmesi gereken tüm yöntemleri virgülle ayırarak listeleyin |
Request header field XXX is not allowed by Access-Control-Allow-Headers | Özel başlık gönderildi ancak Allow-Headers'te beyan edilmedi; en yaygın sorun Content-Type: application/json veya Authorization eklenmemesi | Access-Control-Allow-Headers'te kullanılan tüm istek başlıklarını (basit olmayan türler için Content-Type dahil) listeleyin |
When credentials flag is true, Allow-Origin cannot be wildcard * | Kimlik bilgileri ile istek (withCredentials=true) yapıldığında sunucu Allow-Origin: * döndürüyor, bu spesifikasyon tarafından açıkça yasaklanmıştır | * kullanılamaz, istek Origin'e göre somut kaynak döndürülmelidir; aynı zamanda Allow-Credentials: true olduğunu doğrulayın |
When credentials flag is true, Allow-Headers cannot be wildcard * | Kimlik bilgileri ile istek yapıldığında Allow-Headers * olarak ayarlandı, bazı tarayıcılar (örn. Chrome) buna izin vermez | Kullanılan tüm istek başlıklarını listeleyin, * kullanmayın |
Preflight redirect is not allowed | OPTIONS isteği 3xx yeniden yönlendirmesi döndürdü, tarayıcı preflight isteğinin yeniden yönlendirmesini takip etmiyor | OPTIONS isteğinin doğrudan 200 döndürdüğünden emin olun, yeniden yönlendirmeyin; sunucu yapılandırmasını OPTIONS atlamayacak şekilde düzeltin |
- Kimlik Doğrulama Başlığı Oluşturucu
- Cache-Control Çözümleyici
- Content-Disposition Çözümleyici
- CORS Başlık Oluşturucu
- CORS Denetleyici
- CSP Oluşturucu
- cURL'den Koda Dönüştürücü
- Global DNS Yayılma Kontrolü
- DNS Sorgulama
- Forwarded Başlık Çözümleyici
- Hreflang Etiket Oluşturucu
- HSTS Analizörü
- HTTP Çerez Ayrıştırıcı
- HTTP Başlık Denetleyici
- HTTP İstek Test Aracı
- HTTP Durum Kodları Sorgulama
- IP Sorgulama
- IPv4 Dönüştürücü
- IPv4 Aralık Genişletici
- IPv6 Araç Kutusu
- Link Başlık Ayrıştırıcı
- MX Sorgulama
- Port Denetleyici
- URL Parametre Oluşturucu
- Rate Limit Başlık Ayrıştırıcı
- Yönlendirme Denetleyici
- Robots.txt Oluşturucu
- Robots.txt Denetimi
- Güvenlik Başlığı Denetleyici
- Security.txt Oluşturucu
- Set-Cookie Ayrıştırıcı
- Site Ağ Denetimi
- Sitemap Generator
- Sitemap Denetleyici
- SSL Sertifika Denetleyicisi
- Alt Ağ Hesaplayıcı
- URL Çözümleyici
- User-Agent Ayrıştırıcı
- UTM Bağlantı Oluşturucu
- WebSocket Test Aracı
- What Is My IP?
- WHOIS Sorgulama