CORS跨域檢查器

關於 GeekFormat

跨域診斷面板

由伺服端模擬預檢與實際請求，快速判斷是 Allow-Origin、Allow-Headers 還是 credentials 出了問題。

模擬攜帶憑證用於檢查 Cookie、Authorization 等需要 credentials 的場景。

在伺服器真實模擬CORS預檢與實際請求，6大回應標頭逐項檢查，精準定位跨域設定錯誤，提供Nginx/Node.js/Spring等多框架修復程式碼。

適用場景

瀏覽器主控台出現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原理時，透過實際請求觀察各回應標頭的作用，加深對跨域機制的理解

使用方法

在目標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標頭狀態，根據紅色錯誤項的修復建議調整伺服端設定，修復後重新偵測驗證

功能特點

在伺服器真實模擬預檢請求與實際請求，不受瀏覽器快取和外掛干擾，結果更準確
分離展示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混合內容場景偵測，提示混合內容導致的跨域相關問題

常見問題

為什麼用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://協定的特殊限制）。

故障排查

瀏覽器主控台報 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讀取，瀏覽器會自動過濾

術語表

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 回應標頭完整對照表

回應標頭	作用	取值範例	注意事項

哪些請求會觸發預檢（Preflight）判定表

觸發條件	是否觸發預檢	詳細說明

常見CORS報錯與解決方案速查表

主控台錯誤訊息	根本原因	解決方案