當服務器環境為 IIS（而非 Nginx），且前端、后端部署在不同服務器導致跨域時，核心思路與 Nginx 場景一致，但實現工具從「Nginx」替換為「IIS 配置」。此時依然存在 “后端服務器配置跨域頭” 和 “前端服務器配置反向代理” 兩種方案，無需額外引入 Nginx（除非你主動選擇在 IIS 前端疊加 Nginx）。

一、核心方案對比（IIS 環境）

方案	實現方式	適用場景	推薦優先級
后端 IIS 配置跨域頭	在后端服務器的 IIS 中，通過「HTTP 響應頭」或「URL 重寫模塊」添加 Access-Control-* 頭，允許前端域名請求	1. 有權限修改后端 IIS 配置 2. 多個前端項目共用同一后端 3. 希望減少轉發損耗（前端直接請求后端）	★★★★★
前端 IIS 配置反向代理	在前端服務器的 IIS 中，通過「URL 重寫模塊」配置代理，將前端請求轉發到后端（前端請求同源地址，規避跨域）	1. 無權修改后端配置（如第三方接口） 2. 需隱藏后端真實地址（安全需求） 3. 后端不支持直接配置跨域頭	★★★☆☆

二、詳細實現步驟（IIS 環境）

方案1：后端 IIS 直接配置跨域頭（推薦）

原理：通過后端 IIS 向前端返回「允許跨域」的響應頭（如 Access-Control-Allow-Origin），瀏覽器識別后允許跨域請求，無需轉發。
前提：后端 IIS 需安裝「URL 重寫模塊」（處理預檢請求 OPTIONS，可選但建議安裝，IIS 管理器可直接搜索安裝）。

步驟1：添加跨域響應頭（基礎配置）

1. 打開「后端服務器 IIS 管理器」→ 選中后端站點（如 BackendSite）→ 雙擊「HTTP 響應頭」；
2. 點擊右側「添加」，依次添加以下頭（根據需求調整）：

   響應頭名稱	值（示例）	說明
   Access-Control-Allow-Origin	http://frontend-server.com（前端服務器域名）	允許的前端域名，不能用 *（否則無法攜帶 Cookie）
   Access-Control-Allow-Methods	GET,POST,PUT,DELETE,OPTIONS	允許的請求方法
   Access-Control-Allow-Headers	Content-Type,Authorization	允許的請求頭（如 Token、Content-Type）
   Access-Control-Allow-Credentials	true	允許跨域攜帶 Cookie（如需）
   Access-Control-Max-Age	3600	預檢請求緩存時間（減少 OPTIONS 請求次數）

步驟2：處理預檢請求（OPTIONS 請求）

跨域請求前，瀏覽器會先發 OPTIONS 預檢請求驗證權限，需后端 IIS 正確響應（否則請求失敗）：

1. 選中后端站點 → 雙擊「URL 重寫」→ 點擊右側「添加規則」→ 選擇「空白規則」；
2. 配置規則：
   • 匹配 URL：模式 .*（匹配所有路徑），使用「正則表達式」；
   • 條件：添加條件 → 條件輸入 {REQUEST_METHOD}，模式 ^OPTIONS$（僅匹配 OPTIONS 請求）；
   • 操作：操作類型選擇「自定義響應」，狀態代碼 204（無內容，成功響應），狀態文本 No Content；
3. 保存規則，重啟站點。

優勢：無轉發損耗，前端直接請求后端（如 http://backend-server.com/api/user），性能最優，配置一次生效。

方案2：前端 IIS 配置反向代理（后端不可控時用）

原理：前端代碼請求「與自身同源的地址」（如 http://frontend-server.com/api/user），由前端 IIS 將該請求「轉發」到后端服務器（如 http://backend-server.com/api/user）。瀏覽器認為是同源請求，規避跨域。
前提：前端 IIS 需安裝「URL 重寫模塊」和「應用請求路由（ARR）」（ARR 是 IIS 實現反向代理的核心模塊，可通過 IIS 管理器或微軟官網下載）。

步驟1：啟用 ARR 代理

1. 打開「前端服務器 IIS 管理器」→ 點擊左側服務器名稱（如 WIN-XXXX）→ 雙擊「應用請求路由緩存」；
2. 點擊右側「服務器代理設置」→ 勾選「啟用代理」→ 保存（若提示“需要 URL 重寫模塊”，先安裝該模塊）。

步驟2：配置 URL 重寫規則（轉發請求）

1. 選中前端站點（如 FrontendSite，需先部署前端打包文件，如 dist 目錄）→ 雙擊「URL 重寫」→ 「添加規則」→「空白規則」；
2. 配置規則（以轉發 /api/ 路徑為例）：
   • 匹配 URL：
     模式 ^api/(.*)（匹配所有以 /api/ 開頭的路徑，如 /api/user），使用「正則表達式」；
   • 條件（可選）：無需額外條件；
   • 操作：
     操作類型選擇「重寫」，重寫 URL 填寫 http://backend-server.com/api/{R:1}（{R:1} 是正則捕獲的路徑，如 /user）；
     勾選「停止處理后續規則」（避免其他規則干擾）；
3. 保存規則，重啟前端站點。

步驟3：調整前端代碼

前端請求地址從「后端域名」改為「前端同源路徑」：

// 原跨域請求（錯誤）
axios.get('http://backend-server.com/api/user')// 調整后（通過前端 IIS 轉發）
axios.get('/api/user') // 實際請求 http://frontend-server.com/api/user，由 IIS 轉發到后端

優勢：無需修改后端配置，適合后端不可控場景（如調用第三方接口），且能隱藏后端真實地址。

三、總結

1. 優先選方案1：若能修改后端 IIS 配置，直接添加跨域頭是最直接、高效的方式，無轉發損耗；
2. 備選方案2：若后端不可控（如第三方接口），再用前端 IIS 配置反向代理，需注意調整前端請求路徑。

兩種方案均基于 IIS 原生功能實現，無需額外引入 Nginx（除非你有特殊需求，如在 IIS 前端疊加 Nginx 做負載均衡，但此時配置邏輯與前文 Nginx 方案一致）。