)
簡介面向需要在 Windows 環(huán)境下快速搭建輕量 Web 服務、尤其是調試 ASP 頁面的用戶這份小型工具包提供了一套替代 IIS 的簡易思路。它圍繞可執(zhí)行服務程序、頁面樣式表與說明網頁組織適合個人開發(fā)者、教學演示或舊項目維護場景用于低成本啟動本地站點并驗證動態(tài)頁面運行效果。壓縮包共 3 個文件主要為 exe、css 與 htm 類型體積約 1.01MB結構精簡下載與部署負擔較小。已有 436 人學習或下載說明其對 IIS 替代方案與 ASP 運行環(huán)境感興趣的讀者具有一定參考價值。讀者可借此了解輕量服務器工具的組成方式結合說明頁理解其配置方式并用于 ASP 頁面本地測試、簡易站點發(fā)布或在選型時與 Nginx、Apache、Caddy 等常見方案作入門對比輔助判斷工具是否契合自身開發(fā)與維護需求。1. 換掉 IIS 之前你要換的不是軟件是它替你兜住的那層默認行為去年接手一個跑了七八年的老站點機房要回收那臺 Windows 主機我第一反應是趕緊找個代替 IIS 的軟件越快越好。第一次遷移就翻了車首頁能開后臺上傳接口全掛日志里連一行有用的信息都沒有。查了大半天才發(fā)現(xiàn)問題根本不在新服務器軟件上而在 IIS 里那個我從沒正眼看過的默認請求體大小限制它一直默默兜著這個站點。這件事之后我改了判斷順序先摸清你在 IIS 上依賴了什么再談?chuàng)Q誰。這篇寫給正在做這類決策的人手里可能有靜態(tài)站、有跑了很多年的 ASP.NET 應用、也有新寫的接口服務想知道幾種替代方案各適合誰、動手前要先盤哪些東西、哪一步最容易出事。2. 選型維度給代替 IIS 的軟件排序先定這五把尺子選型最怕上來就比性能跑分。靜態(tài)文件誰快誰慢在你實際并發(fā)量級下基本看不出差別真正讓你半夜爬起來的是證書過期、路徑 404、上傳失敗這類瑣事。我一般按五個維度排托管模型、配置遷移成本、TLS 與可觀測性、生態(tài)與人力最后才是性能。下面逐個說清楚怎么判斷。2.1 托管模型站點是跑在服務器里還是服務器本身就是站點IIS 是典型的容器式模型一臺機器上裝一個服務配置里掛若干個站點每個站點綁主機頭、端口、證書應用池負責隔離和回收。Nginx、Apache、Caddy 都是同一套思路只是換了個配置文件格式。Kestrel 恰好反過來——你的程序本身就是服務器一個進程通常就是一個站點。這個差別決定了遷移工作量。一臺 Windows 主機上掛著七八個站點、共用不同主機頭換成 Kestrel 就意味著七個進程、七份配置、七套守護運維復雜度直接翻倍反過來如果你手上只有兩三個 .NET 應用用 Kestrel 加前置反向代理反而比配置一個通用 Web 服務器更省事。還有一條更硬的判斷線有沒有 Windows 專有依賴。Windows 集成身份驗證、COM 組件、注冊表讀寫、依賴文件鎖的舊代碼、本地消息隊列只要命中其中一項跨平臺這條路基本就堵死了剩下能選的是繼續(xù)留在 Windows 上只是把 IIS 換成別的服務器軟件。我見過太多團隊在這一點上判斷失誤方案選得漂亮最后卡在一個調不動的老 DLL 上。2.2 配置遷移成本web.config 里那些沒人看的規(guī)則才是大頭web.config 是一個容易被低估的坑。它表面上是個配置文件實際上承載了這個站點多年的歷史請求體大小限制、URL 重寫規(guī)則、自定義響應頭、默認文檔、MIME 類型補充、錯誤頁、模塊注冊、授權規(guī)則一層套一層很多條目連原作者都說不清為什么在那兒。判斷成本的方法很土但有效把 web.config 全文撈出來按節(jié)點分類計數(shù)。URL 重寫規(guī)則超過二十條就要單獨排期因為重寫規(guī)則的語義在 Nginx 的 rewrite、Caddy 的 try_files 之間并不一一對應正則寫法、大小寫敏感、尾部斜杠處理都會產生行為差異得逐條對著測。請求體大小、默認文檔、MIME 補充、自定義頭這幾類倒是很快基本是查表替換的活兒。真正花時間的往往不是規(guī)則本身而是規(guī)則背后的隱含假設。比如一條重寫規(guī)則把/api/xxx轉到/api/xxx.ashx在 IIS 上跑得好好的換到新服務器上因為大小寫敏感或者路徑拼接方式不同直接 404。這種問題不看原始配置根本猜不到。2.3 TLS 與進程可觀測性證書續(xù)期和日志這兩件事最容易欠債IIS 的證書綁定是手工活續(xù)期靠人記著這是很多團隊的隱性技術債。換成 Nginx證書還是要自己配、自己續(xù)通?？慷〞r任務加一個重載命令Caddy 把這件事直接內建了只要域名解析正確、80 和 443 可達簽發(fā)和續(xù)期它自己管。如果你的站點數(shù)量多、證書來源雜這一項的權重應該往上調?？捎^測性是另一處容易被忽略的差異。IIS 有 W3C 格式的訪問日志還有失敗請求跟蹤這種能抓到具體模塊和耗時的手段。Nginx 的日志默認字段和 IIS 完全不是一套$remote_addr、$request_time、$upstream_response_time這些字段需要自己組織成log_format否則你原來那套日志分析腳本全部失效。進程守護也一樣IIS 有應用池自動重啟和快速失敗保護Nginx 是主進程帶工作進程工作進程掛了會自動拉起而 Kestrel 單獨跑的話沒有任何守護必須靠 systemd 或容器編排兜底。我把這塊叫黑匣子問題。遷移前先問自己一句出問題時我手上有什么證據。答不上來就先別切流量。2.4 生態(tài)與人力冷門方案省下的性能要用人力還模塊生態(tài)這一項Apache 底子最厚幾十年的模塊積累幾乎任何奇怪需求都能找到現(xiàn)成方案Nginx 的資料量和招人容易度最高出問題搜一下基本有答案Caddy 的配置極簡但遇到冷門需求時文檔深度不如前兩者Kestrel 只在 .NET 圈子里出了圈基本沒人認。還有一條經常被忽略Windows 上的 Nginx 是模擬多工作進程的官方文檔也說明了它在 Windows 上的表現(xiàn)不適合高并發(fā)生產場景。如果你的結論是繼續(xù)留在 Windows 主機上那 Nginx 未必是首選反而 Apache 或者干脆保留 IIS 換掉站點架構更實際。方案選型必須和宿主機綁定在一起考慮脫離部署環(huán)境談優(yōu)劣沒有意義。2.5 五個維度擺在一起看的對照表把上面幾條落成一張表選型會快很多。下表的判斷基于常見的中小型站點遷移場景并發(fā)量級在幾百到幾千 QPS 以內超大流量場景需要重新評估。維度NginxApache HTTP ServerCaddyKestrel 反向代理托管模型站點式配置驅動站點式配置驅動站點式配置驅動進程即站點跨平臺能力強但 Windows 版不建議生產強強強依賴 .NET 運行時配置遷移成本中重寫規(guī)則需逐條翻譯中重寫語法相對接近低配置項少高需改代碼與部署方式證書自動化需自行實現(xiàn)續(xù)期需自行實現(xiàn)續(xù)期內建自動簽發(fā)續(xù)期依賴前置代理日志與排查字段靈活格式需自配字段成熟模塊豐富格式簡潔夠用依賴應用日志與前置代理生態(tài)與資料量大大且老牌中僅限 .NET 生態(tài)適合的站點類型靜態(tài)資源、反向代理入口老應用兼容、模塊依賴重站點多、證書雜純 .NET 服務這張表只是起點具體項目里我會把權重按實際情況調。證書數(shù)量多、運維人手少就把自動化那一列權重加倍老應用多、重寫規(guī)則復雜就把遷移成本那一列權重加倍。3. 四類方案逐項對比Nginx、Apache、Caddy、Kestrel 各能接住什么四個方案不是同一層的東西硬拉在一起比容易失真。準確地說Nginx、Apache、Caddy 是通用 Web 服務器可以獨立承接站點Kestrel 是應用內服務器通常要和前三種之一搭配使用。下面按能接住什么、接不住什么分別說。3.1 Nginx靜態(tài)資源和反向代理入口的默認答案大部分從 IIS 遷走的項目最后都落在 Nginx 上原因很實在靜態(tài)文件處理干凈反向代理配置直觀資源占用低出了問題網上能找到答案。它對應的 IIS 能力大致是站點綁定對應 server 塊URL 重寫對應 rewrite 與 try_files請求過濾對應 client_max_body_size 一類指令自定義響應頭對應 add_header。它的短板也很明確。第三方模塊大多需要重新編譯動態(tài)模塊支持是后來才有的不如 Apache 那種加載即用的體驗配置語法對新手有門檻一個分號漏了就是 500Windows 版本不適合生產證書續(xù)期得自己搭。如果你的站點以靜態(tài)資源加反向代理為主這些短板基本碰不到如果重寫規(guī)則特別復雜翻譯工作量會比想象中大。3.2 Apache HTTP Server老站點和 .htaccess 慣性的退路如果原站點重度依賴 .htaccess 或者大量 Apache 風格的重寫規(guī)則遷移到 Apache 反而最省事。它的模塊生態(tài)最成熟認證、改寫、壓縮、限流都有現(xiàn)成方案配置項的可讀性也比 Nginx 好一些出了錯日志提示相對友好。代價是資源和調優(yōu)復雜度。默認的多進程模型在高并發(fā)下內存占用比 Nginx 高需要根據場景在 prefork、worker、event 幾種模式之間選這個選擇對新手不友好。另外如果原來的站點是經典 ASP 或者老式 WebFormsApache 也接不住那部分只能靠單獨的應用服務器或者整體重寫別指望換個 Web 服務器就解決。3.3 Caddy把證書這件事從運維流程里拿掉Caddy 最大的價值是把 TLS 這件事從運維任務變成默認行為。配置文件里寫個域名證書簽發(fā)和續(xù)期它自己完成不需要你寫定時任務也不會有某張證書忘了續(xù)導致凌晨告警這種事。配置語法也短一個反向代理加靜態(tài)文件服務幾行就寫完對站點數(shù)量多、證書來源雜的環(huán)境特別友好。限制在于生態(tài)。它的模塊數(shù)量比不上前兩者遇到非常規(guī)需求時可能得自己寫插件日志格式雖然能配但周邊分析工具的支持度不如 Nginx 成熟團隊里如果有人只熟悉 Nginx接手 Caddy 需要一點適應時間。我的判斷是如果你的團隊規(guī)模小、站點多、沒人愿意天天盯證書Caddy 的性價比很高。3.4 Kestrel 加反向代理.NET 應用最省心的組合如果站點本身就是 .NET 應用最干凈的做法是讓 Kestrel 只監(jiān)聽回環(huán)地址公網流量統(tǒng)一由前置的 Nginx 或 Caddy 進來。好處是應用和服務器職責分離TLS、靜態(tài)資源、限流、壓縮交給前置業(yè)務邏輯只關心請求升級部署也只是重啟一個進程。關鍵點有三個。第一監(jiān)聽地址必須是127.0.0.1否則外部可以繞過前置代理直連應用端口。第二請求體大小限制要在 Kestrel 里顯式設置IIS 的默認值和 Kestrel 的默認值并不一致直接搬過來很可能上傳失敗。第三必須啟用轉發(fā)頭處理否則應用里拿到的客戶端 IP 永遠是127.0.0.1日志和風控全部失真。下面這段配置把這三件事一次做完。var builder WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(options { // 只監(jiān)聽回環(huán)地址公網流量必須經過前置代理防止繞過 options.ListenLocalhost(5000); // 對應 IIS 的 maxAllowedContentLength默認值往往撐不住大文件上傳 options.Limits.MaxRequestBodySize 100 * 1024 * 1024; // 長上傳或慢客戶端場景下默認的頭部超時可能不夠 options.Limits.RequestHeadersTimeout TimeSpan.FromSeconds(60); }); builder.Services.ConfigureForwardedHeadersOptions(options { options.ForwardedHeaders ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; // 代理與應用同機部署時清空已知網絡跨機部署改成代理所在的內網段 options.KnownNetworks.Clear(); options.KnownProxies.Clear(); }); var app builder.Build(); // 必須放在任何讀取 RemoteIpAddress 的中間件之前 app.UseForwardedHeaders(); app.Run();ListenLocalhost決定了應用端口的暴露范圍改成ListenAnyIP就等于把應用直接掛到公網這一步別圖省事。MaxRequestBodySize的單位是字節(jié)和 IIS 里按 KB 計的maxRequestLength換算容易出錯遷移時對著原配置逐項核一遍。UseForwardedHeaders的位置極其關鍵放在鑒權中間件之后的話限流和審計拿到的仍然是代理地址。3.5 同一個站點在三種方案下的配置對照光看文字不直觀把同一個站點——靜態(tài)資源加/api/反向代理——分別寫成 Nginx 和 Caddy 的配置差異一眼就能看出來。# Nginx站點綁定 靜態(tài)資源 反向代理 server { listen 80; server_name app.internal.example; # 換成你自己的域名 return 301 https://$host$request_uri; } server { listen 443 ssl; http2 on; server_name app.internal.example; ssl_certificate /etc/ssl/site/fullchain.pem; ssl_certificate_key /etc/ssl/site/privkey.pem; # IIS 的請求體限制在這里沒有等價默認值必須顯式放寬 client_max_body_size 100m; client_body_timeout 120s; root /srv/app/wwwroot; index index.html; # 對應 IIS 里 SPA 的 URL 重寫回退規(guī)則 location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:5000; proxy_http_version 1.1; # 這幾行決定了后端能不能拿到真實客戶端信息 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket 與長連接場景必須顯式聲明 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 120s; } }# Caddy同樣的站點證書由它自己申請和續(xù)期 app.internal.example { encode gzip zstd root * /srv/app/wwwroot # 反向代理規(guī)則寫在前面命中 /api/ 的請求不進靜態(tài)文件邏輯 handle /api/* { reverse_proxy 127.0.0.1:5000 { header_up X-Real-IP {remote_host} } } # SPA 回退找不到文件時交給 index.html try_files {path} /index.html file_server }兩份配置的差別不只是行數(shù)。Nginx 版本里證書路徑、續(xù)期任務、日志格式、請求體限制全部要人寫Caddy 版本里證書那一段直接消失了請求體限制默認就足夠寬松代價是你對細節(jié)的掌控少一些。遷移時我的習慣是先寫 Caddy 版本驗證業(yè)務能不能跑通確認沒問題再決定要不要換成 Nginx 做精細調優(yōu)這樣能快速排掉是不是服務器軟件的問題這類干擾。4. 遷移實戰(zhàn)從 IIS 站點到新服務器的四步走方案定下來之后真正的活兒才開始。整個遷移我會拆成四步盤點、分類、改寫、切換。順序不能亂跳過盤點直接改配置大概率會在某個不起眼的模塊上翻車。4.1 遷移前盤點五張清單缺一不可盤點做得越細后面返工越少。我一般會整理出五張清單缺一張都會在切換當天出問題。清單要記錄的內容漏了會怎樣站點與應用池站點名、物理路徑、應用池身份、32/64 位設置、啟動模式權限不對導致 500或舊組件加載失敗綁定信息協(xié)議、端口、主機頭、證書、是否需要 SNI多站點共用 IP 時綁錯串站配置文件web.config 全文、重寫規(guī)則、模塊注冊、自定義頭重寫規(guī)則漏翻頁面 404外部依賴數(shù)據庫連接、文件共享、定時任務、第三方接口白名單切換后接口全超時可寫目錄上傳目錄、日志目錄、緩存目錄上傳失敗且日志里看不出原因第一張清單里最容易漏的是應用池身份。IIS 里站點默認以某個應用池身份運行這個身份對物理路徑、對數(shù)據庫、對共享目錄都有授權換成新服務器后進程用戶變了權限全斷。第二張里最容易漏的是 SNI一臺機器多個證書時沒有 SNI 會返回錯誤的證書。4.2 三類站點的搬遷路徑不同類型站點的做法差別很大混在一起談容易誤導。純靜態(tài)站最簡單文件拷過去注意保留目錄結構和文件名大小寫寫一個 server 塊或者一段 Caddyfile加上緩存頭和壓縮基本就完事。唯一要小心的是中文文件名和原來依賴的默認文檔順序。.NET 應用分兩種。較新的框架版本本身跨平臺直接把發(fā)布產物拷到目標機器用 Kestrel 跑起來前置加一層反向代理配置文件里的連接字符串和路徑改成新環(huán)境的。老一些的 WebForms 或者重度依賴 Windows 組件的項目不要硬遷讓它留在 Windows 上只是把 IIS 換成反向代理 應用內服務器的組合先把入口層統(tǒng)一應用本身慢慢重寫。經典 ASP 這類老技術棧基本沒有官方跨平臺方案?，F(xiàn)實做法是繼續(xù)保留一臺 Windows 主機專門跑它外面統(tǒng)一用一層反向代理把流量分過來等業(yè)務下線或者重寫到新框架再徹底關掉。這個決定不好看但比強行遷移再回滾要省事得多。4.3 配置改寫對照從 web.config 到新配置改寫階段最實用的是一張對照表照著填比憑記憶靠譜。IIS 配置位置作用新方案對應做法httpRuntime maxRequestLength請求體大小KBNginxclient_max_body_sizeKestrelMaxRequestBodySizerequestFiltering maxAllowedContentLength請求體大小字節(jié)同上注意單位換算rewrite/rulesURL 重寫Nginxrewrite/try_filesCaddyrewrite/try_fileshttpProtocol customHeaders自定義響應頭Nginxadd_headerCaddyheaderdefaultDocument默認文檔順序NginxindexstaticContent mimeMap補充 MIME 類型Nginxtypes塊Caddy 多數(shù)內置httpErrors自定義錯誤頁Nginxerror_pageapplicationInitialization應用預熱systemd 啟動順序容器健康檢查security/authenticationWindows 集成認證需單獨方案通常改為統(tǒng)一認證網關重寫規(guī)則是最容易出錯的一塊。IIS 的規(guī)則里常見^$、^(.)$這類寫法配合{R:1}做反向引用翻譯到 Nginx 時要換成$1同時注意rewrite默認在 server 上下文里對 URI 做匹配而location匹配的是解碼后的路徑。尾部斜杠尤其坑人IIS 默認對目錄補斜杠Nginx 需要try_files $uri $uri/才會做同樣的事少寫一個$uri/目錄訪問就變成 404。4.4 切換與驗證灰度、回滾、驗收項切換那天不要一次性把流量全切過去。我的做法是讓新舊兩套并行跑一段時間先通過內網 hosts 或者測試域名驗證功能再按比例把流量引到新服務器觀察至少一個完整業(yè)務周期。日志里的 5xx 比例、接口平均耗時、上傳成功率這三個指標是核心觀察項。回滾開關必須提前準備好而且要是停流量而不是停服務——舊服務器保持運行狀態(tài)只是不接新流量出問題時改一行上游配置就能切回來。這一條是后悔藥希望你用不上但一定要有。驗收項至少覆蓋首頁與深層鏈接、登錄與鑒權、文件上傳下載含大文件、帶中文的參數(shù)與文件名、靜態(tài)資源緩存命中、WebSocket 或長輪詢連接、錯誤頁返回碼、以及日志里客戶端 IP 是否真實。每一條都實際點一遍別只看監(jiān)控面板上的曲線。5. 避坑與排查遷移路上最容易翻車的五個點下面這五條是我自己或者身邊人真實踩過的按「現(xiàn)象 → 原因 → 解決」寫遇到同類問題時可以直接對照。5.1 上傳接口集體失敗返回 413 或 500現(xiàn)象站點其他功能正常只有上傳接口掛掉小文件能傳超過幾兆就失敗日志里要么是 413要么是一句沒有上下文的 500。原因IIS 里maxRequestLength和maxAllowedContentLength兩個限制同時存在一個按 KB 一個按字節(jié)很多人只調了其中一個。換到新服務器后這兩個限制都不存在了取而代之的是 Nginx 的client_max_body_size默認值很小和 Kestrel 的MaxRequestBodySize默認也有上限任何一層沒放開都會攔下來。解決把鏈路每一層的限制都顯式寫出來Nginx 的client_max_body_size、Kestrel 的MaxRequestBodySize、以及應用框架自身如果有獨立限制也要一起改。改完用一個剛好超過原限制的文件實測別用幾十 K 的小文件自欺欺人。另外client_body_timeout也要跟著調大文件慢速上傳時默認超時會提前斷開。5.2 日志里客戶端 IP 全變成 127.0.0.1現(xiàn)象切換后風控規(guī)則全部失效日志里所有請求的來源地址都是本機回環(huán)地址限流和黑名單形同虛設。原因請求經過了前置反向代理應用看到的是代理的地址。IIS 時代如果啟用了反向代理模塊它會幫忙處理轉發(fā)頭換成 Nginx 加 Kestrel 之后轉發(fā)頭需要顯式設置和顯式信任缺任何一環(huán)都不生效。解決代理側加proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for和X-Forwarded-Proto應用側啟用轉發(fā)頭中間件并把它放在管道最前面。如果是跨機部署還要把代理所在的內網段加進已知網絡否則框架出于安全考慮會忽略這些頭。驗證方法很直接隨便發(fā)一個請求看應用日志里記錄的 IP 是不是你自己的出口地址。5.3 Linux 上路徑大小寫不一致導致 404現(xiàn)象頁面能打開但部分圖片、樣式、接口 404開發(fā)環(huán)境完全正常。原因原來跑在 Windows 上文件系統(tǒng)對大小寫不敏感代碼里寫~/Content/Site.css還是~/content/site.css都能找到文件換到大小寫敏感的文件系統(tǒng)后只要有一個字母對不上就是 404。反斜杠也是同理\在 Windows 里是路徑分隔符在別的系統(tǒng)里不是。解決遷移前用腳本掃一遍代碼和配置里的靜態(tài)資源引用把大小寫和分隔符統(tǒng)一。已經上線的環(huán)境可以用訪問日志里的 404 路徑反查實際文件名逐個修正。長期做法是在構建流程里加一步校驗避免以后再犯。5.4 中文文件名和 URL 參數(shù)出現(xiàn)亂碼現(xiàn)象下載文件名變成一串百分號編碼或者帶中文的查詢參數(shù)到后端變成問號。原因文件系統(tǒng)編碼、HTTP 響應頭編碼、頁面編碼三者不一致。IIS 環(huán)境下很多項目默認走的是本地編碼遷到新環(huán)境后統(tǒng)一成了 UTF-8原來恰好能跑的代碼就暴露了問題。下載場景里常見的是Content-Disposition只寫了filename沒有按規(guī)范補filename*。解決統(tǒng)一全鏈路 UTF-8包括文件系統(tǒng)、應用配置、響應頭、數(shù)據庫連接。下載接口按規(guī)范同時輸出filename和filename*兩個參數(shù)兼容舊客戶端。URL 里的中文參數(shù)在代理層不要做二次編碼Nginx 默認會對 URI 做一次解碼配置里如果開了二次解碼反而會亂。5.5 WebSocket 和長連接在代理后面連不上現(xiàn)象實時推送功能在測試環(huán)境正常切換后一直 502 或者連接幾秒就斷。原因WebSocket 需要Upgrade和Connection兩個頭透傳Nginx 默認不透傳這兩項另外長連接的空閑超時默認值偏短連接被代理主動斷掉。如果用了平滑重載工作進程退出時也會把長連接一起切斷。解決代理的 location 里顯式加proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection upgrade把proxy_read_timeout調到業(yè)務能接受的范圍。重載時設置工作進程的優(yōu)雅退出時間讓存量連接自然結束再退出。切換前一定要單獨測一遍實時功能這類問題不會在普通頁面上暴露出來。6. 按場景落地三個答案加一條驗證命令把上面的內容收成三個可執(zhí)行的判斷你對號入座就行。你的場景推薦方案核心理由站點多、證書雜、運維人手少Caddy 獨立承接證書自動簽發(fā)續(xù)期配置量最小以靜態(tài)資源和反向代理為主團隊熟悉主流方案Nginx 獨立承接資料多、招人容易、調優(yōu)空間大純 .NET 服務追求部署簡單Kestrel 加 Nginx 或 Caddy 前置應用與服務器職責分離升級只重啟進程依賴 Windows 組件或經典 ASP保留 Windows 主機入口層換反向代理硬遷成本遠高于分層過渡定完方案之后別急著切流量先跑一條最樸素的驗證命令。下面這段用 curl 把整條鏈路的關鍵行為一次性驗一遍包括大文件上傳、轉發(fā)頭、錯誤頁返回碼。# 1. 大文件上傳驗證請求體限制是否放開構造 50MB 隨機文件 head -c 52428800 /dev/urandom /tmp/probe.bin curl -s -o /dev/null -w upload:%{http_code}\n \ -F file/tmp/probe.bin https://app.internal.example/api/upload # 2. 轉發(fā)頭確認后端拿到的客戶端地址不是 127.0.0.1 curl -s https://app.internal.example/api/whoami # 3. 深層鏈接確認 SPA 回退規(guī)則生效返回 200 而不是 404 curl -s -o /dev/null -w spa:%{http_code}\n \ https://app.internal.example/some/deep/route # 4. 錯誤頁請求不存在的接口確認返回碼和自定義頁都符合預期 curl -s -o /dev/null -w error:%{http_code}\n \ https://app.internal.example/api/not-exist四個檢查項分別對應四類最容易出問題的地方。第一項失敗說明請求體限制沒改全第二項失敗說明轉發(fā)頭鏈路斷了第三項失敗說明重寫或回退規(guī)則翻錯了第四項失敗多半是錯誤頁配置把返回碼一并改成了 200而返回碼被改寫會直接影響監(jiān)控告警和搜索引擎行為比頁面顯示錯誤更隱蔽。說實話我最早做這類遷移時吃過最大的虧不是技術選型選錯而是沒把「原環(huán)境到底依賴了什么」當回事。那次上傳翻車之后我給自己定了個死規(guī)矩不管站點多小動手前必須把 web.config 從頭到尾讀一遍把每一條限制、每一條重寫規(guī)則都抄到一張表上逐條標注在新環(huán)境怎么落地。這個動作看著笨但它把不確定性從切換當天才發(fā)現(xiàn)挪到了動手之前就清楚后面所有事都輕松了。希望這些踩坑記錄能幫你少走一段彎路。本文還有配套的精品資源點擊獲取 IIS遷移選型與避坑：四類Web服務器對比實戰(zhàn)
簡介面向需要在 Windows 環(huán)境下快速搭建輕量 Web 服務、尤其是調試 ASP 頁面的用戶這份小型工具包提供了一套替代 IIS 的簡易思路。它圍繞可執(zhí)行服務程序、頁面樣式表與說明網頁組織適合個人開發(fā)者、教學演示或舊項目維護場景用于低成本啟動本地站點并驗證動態(tài)頁面運行效果。壓縮包共 3 個文件主要為 exe、css 與 htm 類型體積約 1.01MB結構精簡下載與部署負擔較小。已有 436 人學習或下載說明其對 IIS 替代方案與 ASP 運行環(huán)境感興趣的讀者具有一定參考價值。讀者可借此了解輕量服務器工具的組成方式結合說明頁理解其配置方式并用于 ASP 頁面本地測試、簡易站點發(fā)布或在選型時與 Nginx、Apache、Caddy 等常見方案作入門對比輔助判斷工具是否契合自身開發(fā)與維護需求。1. 換掉 IIS 之前你要換的不是軟件是它替你兜住的那層默認行為去年接手一個跑了七八年的老站點機房要回收那臺 Windows 主機我第一反應是趕緊找個代替 IIS 的軟件越快越好。第一次遷移就翻了車首頁能開后臺上傳接口全掛日志里連一行有用的信息都沒有。查了大半天才發(fā)現(xiàn)問題根本不在新服務器軟件上而在 IIS 里那個我從沒正眼看過的默認請求體大小限制它一直默默兜著這個站點。這件事之后我改了判斷順序先摸清你在 IIS 上依賴了什么再談?chuàng)Q誰。這篇寫給正在做這類決策的人手里可能有靜態(tài)站、有跑了很多年的 ASP.NET 應用、也有新寫的接口服務想知道幾種替代方案各適合誰、動手前要先盤哪些東西、哪一步最容易出事。2. 選型維度給代替 IIS 的軟件排序先定這五把尺子選型最怕上來就比性能跑分。靜態(tài)文件誰快誰慢在你實際并發(fā)量級下基本看不出差別真正讓你半夜爬起來的是證書過期、路徑 404、上傳失敗這類瑣事。我一般按五個維度排托管模型、配置遷移成本、TLS 與可觀測性、生態(tài)與人力最后才是性能。下面逐個說清楚怎么判斷。2.1 托管模型站點是跑在服務器里還是服務器本身就是站點IIS 是典型的容器式模型一臺機器上裝一個服務配置里掛若干個站點每個站點綁主機頭、端口、證書應用池負責隔離和回收。Nginx、Apache、Caddy 都是同一套思路只是換了個配置文件格式。Kestrel 恰好反過來——你的程序本身就是服務器一個進程通常就是一個站點。這個差別決定了遷移工作量。一臺 Windows 主機上掛著七八個站點、共用不同主機頭換成 Kestrel 就意味著七個進程、七份配置、七套守護運維復雜度直接翻倍反過來如果你手上只有兩三個 .NET 應用用 Kestrel 加前置反向代理反而比配置一個通用 Web 服務器更省事。還有一條更硬的判斷線有沒有 Windows 專有依賴。Windows 集成身份驗證、COM 組件、注冊表讀寫、依賴文件鎖的舊代碼、本地消息隊列只要命中其中一項跨平臺這條路基本就堵死了剩下能選的是繼續(xù)留在 Windows 上只是把 IIS 換成別的服務器軟件。我見過太多團隊在這一點上判斷失誤方案選得漂亮最后卡在一個調不動的老 DLL 上。2.2 配置遷移成本web.config 里那些沒人看的規(guī)則才是大頭web.config 是一個容易被低估的坑。它表面上是個配置文件實際上承載了這個站點多年的歷史請求體大小限制、URL 重寫規(guī)則、自定義響應頭、默認文檔、MIME 類型補充、錯誤頁、模塊注冊、授權規(guī)則一層套一層很多條目連原作者都說不清為什么在那兒。判斷成本的方法很土但有效把 web.config 全文撈出來按節(jié)點分類計數(shù)。URL 重寫規(guī)則超過二十條就要單獨排期因為重寫規(guī)則的語義在 Nginx 的 rewrite、Caddy 的 try_files 之間并不一一對應正則寫法、大小寫敏感、尾部斜杠處理都會產生行為差異得逐條對著測。請求體大小、默認文檔、MIME 補充、自定義頭這幾類倒是很快基本是查表替換的活兒。真正花時間的往往不是規(guī)則本身而是規(guī)則背后的隱含假設。比如一條重寫規(guī)則把/api/xxx轉到/api/xxx.ashx在 IIS 上跑得好好的換到新服務器上因為大小寫敏感或者路徑拼接方式不同直接 404。這種問題不看原始配置根本猜不到。2.3 TLS 與進程可觀測性證書續(xù)期和日志這兩件事最容易欠債IIS 的證書綁定是手工活續(xù)期靠人記著這是很多團隊的隱性技術債。換成 Nginx證書還是要自己配、自己續(xù)通?？慷〞r任務加一個重載命令Caddy 把這件事直接內建了只要域名解析正確、80 和 443 可達簽發(fā)和續(xù)期它自己管。如果你的站點數(shù)量多、證書來源雜這一項的權重應該往上調?？捎^測性是另一處容易被忽略的差異。IIS 有 W3C 格式的訪問日志還有失敗請求跟蹤這種能抓到具體模塊和耗時的手段。Nginx 的日志默認字段和 IIS 完全不是一套$remote_addr、$request_time、$upstream_response_time這些字段需要自己組織成log_format否則你原來那套日志分析腳本全部失效。進程守護也一樣IIS 有應用池自動重啟和快速失敗保護Nginx 是主進程帶工作進程工作進程掛了會自動拉起而 Kestrel 單獨跑的話沒有任何守護必須靠 systemd 或容器編排兜底。我把這塊叫黑匣子問題。遷移前先問自己一句出問題時我手上有什么證據。答不上來就先別切流量。2.4 生態(tài)與人力冷門方案省下的性能要用人力還模塊生態(tài)這一項Apache 底子最厚幾十年的模塊積累幾乎任何奇怪需求都能找到現(xiàn)成方案Nginx 的資料量和招人容易度最高出問題搜一下基本有答案Caddy 的配置極簡但遇到冷門需求時文檔深度不如前兩者Kestrel 只在 .NET 圈子里出了圈基本沒人認。還有一條經常被忽略Windows 上的 Nginx 是模擬多工作進程的官方文檔也說明了它在 Windows 上的表現(xiàn)不適合高并發(fā)生產場景。如果你的結論是繼續(xù)留在 Windows 主機上那 Nginx 未必是首選反而 Apache 或者干脆保留 IIS 換掉站點架構更實際。方案選型必須和宿主機綁定在一起考慮脫離部署環(huán)境談優(yōu)劣沒有意義。2.5 五個維度擺在一起看的對照表把上面幾條落成一張表選型會快很多。下表的判斷基于常見的中小型站點遷移場景并發(fā)量級在幾百到幾千 QPS 以內超大流量場景需要重新評估。維度NginxApache HTTP ServerCaddyKestrel 反向代理托管模型站點式配置驅動站點式配置驅動站點式配置驅動進程即站點跨平臺能力強但 Windows 版不建議生產強強強依賴 .NET 運行時配置遷移成本中重寫規(guī)則需逐條翻譯中重寫語法相對接近低配置項少高需改代碼與部署方式證書自動化需自行實現(xiàn)續(xù)期需自行實現(xiàn)續(xù)期內建自動簽發(fā)續(xù)期依賴前置代理日志與排查字段靈活格式需自配字段成熟模塊豐富格式簡潔夠用依賴應用日志與前置代理生態(tài)與資料量大大且老牌中僅限 .NET 生態(tài)適合的站點類型靜態(tài)資源、反向代理入口老應用兼容、模塊依賴重站點多、證書雜純 .NET 服務這張表只是起點具體項目里我會把權重按實際情況調。證書數(shù)量多、運維人手少就把自動化那一列權重加倍老應用多、重寫規(guī)則復雜就把遷移成本那一列權重加倍。3. 四類方案逐項對比Nginx、Apache、Caddy、Kestrel 各能接住什么四個方案不是同一層的東西硬拉在一起比容易失真。準確地說Nginx、Apache、Caddy 是通用 Web 服務器可以獨立承接站點Kestrel 是應用內服務器通常要和前三種之一搭配使用。下面按能接住什么、接不住什么分別說。3.1 Nginx靜態(tài)資源和反向代理入口的默認答案大部分從 IIS 遷走的項目最后都落在 Nginx 上原因很實在靜態(tài)文件處理干凈反向代理配置直觀資源占用低出了問題網上能找到答案。它對應的 IIS 能力大致是站點綁定對應 server 塊URL 重寫對應 rewrite 與 try_files請求過濾對應 client_max_body_size 一類指令自定義響應頭對應 add_header。它的短板也很明確。第三方模塊大多需要重新編譯動態(tài)模塊支持是后來才有的不如 Apache 那種加載即用的體驗配置語法對新手有門檻一個分號漏了就是 500Windows 版本不適合生產證書續(xù)期得自己搭。如果你的站點以靜態(tài)資源加反向代理為主這些短板基本碰不到如果重寫規(guī)則特別復雜翻譯工作量會比想象中大。3.2 Apache HTTP Server老站點和 .htaccess 慣性的退路如果原站點重度依賴 .htaccess 或者大量 Apache 風格的重寫規(guī)則遷移到 Apache 反而最省事。它的模塊生態(tài)最成熟認證、改寫、壓縮、限流都有現(xiàn)成方案配置項的可讀性也比 Nginx 好一些出了錯日志提示相對友好。代價是資源和調優(yōu)復雜度。默認的多進程模型在高并發(fā)下內存占用比 Nginx 高需要根據場景在 prefork、worker、event 幾種模式之間選這個選擇對新手不友好。另外如果原來的站點是經典 ASP 或者老式 WebFormsApache 也接不住那部分只能靠單獨的應用服務器或者整體重寫別指望換個 Web 服務器就解決。3.3 Caddy把證書這件事從運維流程里拿掉Caddy 最大的價值是把 TLS 這件事從運維任務變成默認行為。配置文件里寫個域名證書簽發(fā)和續(xù)期它自己完成不需要你寫定時任務也不會有某張證書忘了續(xù)導致凌晨告警這種事。配置語法也短一個反向代理加靜態(tài)文件服務幾行就寫完對站點數(shù)量多、證書來源雜的環(huán)境特別友好。限制在于生態(tài)。它的模塊數(shù)量比不上前兩者遇到非常規(guī)需求時可能得自己寫插件日志格式雖然能配但周邊分析工具的支持度不如 Nginx 成熟團隊里如果有人只熟悉 Nginx接手 Caddy 需要一點適應時間。我的判斷是如果你的團隊規(guī)模小、站點多、沒人愿意天天盯證書Caddy 的性價比很高。3.4 Kestrel 加反向代理.NET 應用最省心的組合如果站點本身就是 .NET 應用最干凈的做法是讓 Kestrel 只監(jiān)聽回環(huán)地址公網流量統(tǒng)一由前置的 Nginx 或 Caddy 進來。好處是應用和服務器職責分離TLS、靜態(tài)資源、限流、壓縮交給前置業(yè)務邏輯只關心請求升級部署也只是重啟一個進程。關鍵點有三個。第一監(jiān)聽地址必須是127.0.0.1否則外部可以繞過前置代理直連應用端口。第二請求體大小限制要在 Kestrel 里顯式設置IIS 的默認值和 Kestrel 的默認值并不一致直接搬過來很可能上傳失敗。第三必須啟用轉發(fā)頭處理否則應用里拿到的客戶端 IP 永遠是127.0.0.1日志和風控全部失真。下面這段配置把這三件事一次做完。var builder WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(options { // 只監(jiān)聽回環(huán)地址公網流量必須經過前置代理防止繞過 options.ListenLocalhost(5000); // 對應 IIS 的 maxAllowedContentLength默認值往往撐不住大文件上傳 options.Limits.MaxRequestBodySize 100 * 1024 * 1024; // 長上傳或慢客戶端場景下默認的頭部超時可能不夠 options.Limits.RequestHeadersTimeout TimeSpan.FromSeconds(60); }); builder.Services.ConfigureForwardedHeadersOptions(options { options.ForwardedHeaders ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; // 代理與應用同機部署時清空已知網絡跨機部署改成代理所在的內網段 options.KnownNetworks.Clear(); options.KnownProxies.Clear(); }); var app builder.Build(); // 必須放在任何讀取 RemoteIpAddress 的中間件之前 app.UseForwardedHeaders(); app.Run();ListenLocalhost決定了應用端口的暴露范圍改成ListenAnyIP就等于把應用直接掛到公網這一步別圖省事。MaxRequestBodySize的單位是字節(jié)和 IIS 里按 KB 計的maxRequestLength換算容易出錯遷移時對著原配置逐項核一遍。UseForwardedHeaders的位置極其關鍵放在鑒權中間件之后的話限流和審計拿到的仍然是代理地址。3.5 同一個站點在三種方案下的配置對照光看文字不直觀把同一個站點——靜態(tài)資源加/api/反向代理——分別寫成 Nginx 和 Caddy 的配置差異一眼就能看出來。# Nginx站點綁定 靜態(tài)資源 反向代理 server { listen 80; server_name app.internal.example; # 換成你自己的域名 return 301 https://$host$request_uri; } server { listen 443 ssl; http2 on; server_name app.internal.example; ssl_certificate /etc/ssl/site/fullchain.pem; ssl_certificate_key /etc/ssl/site/privkey.pem; # IIS 的請求體限制在這里沒有等價默認值必須顯式放寬 client_max_body_size 100m; client_body_timeout 120s; root /srv/app/wwwroot; index index.html; # 對應 IIS 里 SPA 的 URL 重寫回退規(guī)則 location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:5000; proxy_http_version 1.1; # 這幾行決定了后端能不能拿到真實客戶端信息 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket 與長連接場景必須顯式聲明 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 120s; } }# Caddy同樣的站點證書由它自己申請和續(xù)期 app.internal.example { encode gzip zstd root * /srv/app/wwwroot # 反向代理規(guī)則寫在前面命中 /api/ 的請求不進靜態(tài)文件邏輯 handle /api/* { reverse_proxy 127.0.0.1:5000 { header_up X-Real-IP {remote_host} } } # SPA 回退找不到文件時交給 index.html try_files {path} /index.html file_server }兩份配置的差別不只是行數(shù)。Nginx 版本里證書路徑、續(xù)期任務、日志格式、請求體限制全部要人寫Caddy 版本里證書那一段直接消失了請求體限制默認就足夠寬松代價是你對細節(jié)的掌控少一些。遷移時我的習慣是先寫 Caddy 版本驗證業(yè)務能不能跑通確認沒問題再決定要不要換成 Nginx 做精細調優(yōu)這樣能快速排掉是不是服務器軟件的問題這類干擾。4. 遷移實戰(zhàn)從 IIS 站點到新服務器的四步走方案定下來之后真正的活兒才開始。整個遷移我會拆成四步盤點、分類、改寫、切換。順序不能亂跳過盤點直接改配置大概率會在某個不起眼的模塊上翻車。4.1 遷移前盤點五張清單缺一不可盤點做得越細后面返工越少。我一般會整理出五張清單缺一張都會在切換當天出問題。清單要記錄的內容漏了會怎樣站點與應用池站點名、物理路徑、應用池身份、32/64 位設置、啟動模式權限不對導致 500或舊組件加載失敗綁定信息協(xié)議、端口、主機頭、證書、是否需要 SNI多站點共用 IP 時綁錯串站配置文件web.config 全文、重寫規(guī)則、模塊注冊、自定義頭重寫規(guī)則漏翻頁面 404外部依賴數(shù)據庫連接、文件共享、定時任務、第三方接口白名單切換后接口全超時可寫目錄上傳目錄、日志目錄、緩存目錄上傳失敗且日志里看不出原因第一張清單里最容易漏的是應用池身份。IIS 里站點默認以某個應用池身份運行這個身份對物理路徑、對數(shù)據庫、對共享目錄都有授權換成新服務器后進程用戶變了權限全斷。第二張里最容易漏的是 SNI一臺機器多個證書時沒有 SNI 會返回錯誤的證書。4.2 三類站點的搬遷路徑不同類型站點的做法差別很大混在一起談容易誤導。純靜態(tài)站最簡單文件拷過去注意保留目錄結構和文件名大小寫寫一個 server 塊或者一段 Caddyfile加上緩存頭和壓縮基本就完事。唯一要小心的是中文文件名和原來依賴的默認文檔順序。.NET 應用分兩種。較新的框架版本本身跨平臺直接把發(fā)布產物拷到目標機器用 Kestrel 跑起來前置加一層反向代理配置文件里的連接字符串和路徑改成新環(huán)境的。老一些的 WebForms 或者重度依賴 Windows 組件的項目不要硬遷讓它留在 Windows 上只是把 IIS 換成反向代理 應用內服務器的組合先把入口層統(tǒng)一應用本身慢慢重寫。經典 ASP 這類老技術棧基本沒有官方跨平臺方案?，F(xiàn)實做法是繼續(xù)保留一臺 Windows 主機專門跑它外面統(tǒng)一用一層反向代理把流量分過來等業(yè)務下線或者重寫到新框架再徹底關掉。這個決定不好看但比強行遷移再回滾要省事得多。4.3 配置改寫對照從 web.config 到新配置改寫階段最實用的是一張對照表照著填比憑記憶靠譜。IIS 配置位置作用新方案對應做法httpRuntime maxRequestLength請求體大小KBNginxclient_max_body_sizeKestrelMaxRequestBodySizerequestFiltering maxAllowedContentLength請求體大小字節(jié)同上注意單位換算rewrite/rulesURL 重寫Nginxrewrite/try_filesCaddyrewrite/try_fileshttpProtocol customHeaders自定義響應頭Nginxadd_headerCaddyheaderdefaultDocument默認文檔順序NginxindexstaticContent mimeMap補充 MIME 類型Nginxtypes塊Caddy 多數(shù)內置httpErrors自定義錯誤頁Nginxerror_pageapplicationInitialization應用預熱systemd 啟動順序容器健康檢查security/authenticationWindows 集成認證需單獨方案通常改為統(tǒng)一認證網關重寫規(guī)則是最容易出錯的一塊。IIS 的規(guī)則里常見^$、^(.)$這類寫法配合{R:1}做反向引用翻譯到 Nginx 時要換成$1同時注意rewrite默認在 server 上下文里對 URI 做匹配而location匹配的是解碼后的路徑。尾部斜杠尤其坑人IIS 默認對目錄補斜杠Nginx 需要try_files $uri $uri/才會做同樣的事少寫一個$uri/目錄訪問就變成 404。4.4 切換與驗證灰度、回滾、驗收項切換那天不要一次性把流量全切過去。我的做法是讓新舊兩套并行跑一段時間先通過內網 hosts 或者測試域名驗證功能再按比例把流量引到新服務器觀察至少一個完整業(yè)務周期。日志里的 5xx 比例、接口平均耗時、上傳成功率這三個指標是核心觀察項。回滾開關必須提前準備好而且要是停流量而不是停服務——舊服務器保持運行狀態(tài)只是不接新流量出問題時改一行上游配置就能切回來。這一條是后悔藥希望你用不上但一定要有。驗收項至少覆蓋首頁與深層鏈接、登錄與鑒權、文件上傳下載含大文件、帶中文的參數(shù)與文件名、靜態(tài)資源緩存命中、WebSocket 或長輪詢連接、錯誤頁返回碼、以及日志里客戶端 IP 是否真實。每一條都實際點一遍別只看監(jiān)控面板上的曲線。5. 避坑與排查遷移路上最容易翻車的五個點下面這五條是我自己或者身邊人真實踩過的按「現(xiàn)象 → 原因 → 解決」寫遇到同類問題時可以直接對照。5.1 上傳接口集體失敗返回 413 或 500現(xiàn)象站點其他功能正常只有上傳接口掛掉小文件能傳超過幾兆就失敗日志里要么是 413要么是一句沒有上下文的 500。原因IIS 里maxRequestLength和maxAllowedContentLength兩個限制同時存在一個按 KB 一個按字節(jié)很多人只調了其中一個。換到新服務器后這兩個限制都不存在了取而代之的是 Nginx 的client_max_body_size默認值很小和 Kestrel 的MaxRequestBodySize默認也有上限任何一層沒放開都會攔下來。解決把鏈路每一層的限制都顯式寫出來Nginx 的client_max_body_size、Kestrel 的MaxRequestBodySize、以及應用框架自身如果有獨立限制也要一起改。改完用一個剛好超過原限制的文件實測別用幾十 K 的小文件自欺欺人。另外client_body_timeout也要跟著調大文件慢速上傳時默認超時會提前斷開。5.2 日志里客戶端 IP 全變成 127.0.0.1現(xiàn)象切換后風控規(guī)則全部失效日志里所有請求的來源地址都是本機回環(huán)地址限流和黑名單形同虛設。原因請求經過了前置反向代理應用看到的是代理的地址。IIS 時代如果啟用了反向代理模塊它會幫忙處理轉發(fā)頭換成 Nginx 加 Kestrel 之后轉發(fā)頭需要顯式設置和顯式信任缺任何一環(huán)都不生效。解決代理側加proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for和X-Forwarded-Proto應用側啟用轉發(fā)頭中間件并把它放在管道最前面。如果是跨機部署還要把代理所在的內網段加進已知網絡否則框架出于安全考慮會忽略這些頭。驗證方法很直接隨便發(fā)一個請求看應用日志里記錄的 IP 是不是你自己的出口地址。5.3 Linux 上路徑大小寫不一致導致 404現(xiàn)象頁面能打開但部分圖片、樣式、接口 404開發(fā)環(huán)境完全正常。原因原來跑在 Windows 上文件系統(tǒng)對大小寫不敏感代碼里寫~/Content/Site.css還是~/content/site.css都能找到文件換到大小寫敏感的文件系統(tǒng)后只要有一個字母對不上就是 404。反斜杠也是同理\在 Windows 里是路徑分隔符在別的系統(tǒng)里不是。解決遷移前用腳本掃一遍代碼和配置里的靜態(tài)資源引用把大小寫和分隔符統(tǒng)一。已經上線的環(huán)境可以用訪問日志里的 404 路徑反查實際文件名逐個修正。長期做法是在構建流程里加一步校驗避免以后再犯。5.4 中文文件名和 URL 參數(shù)出現(xiàn)亂碼現(xiàn)象下載文件名變成一串百分號編碼或者帶中文的查詢參數(shù)到后端變成問號。原因文件系統(tǒng)編碼、HTTP 響應頭編碼、頁面編碼三者不一致。IIS 環(huán)境下很多項目默認走的是本地編碼遷到新環(huán)境后統(tǒng)一成了 UTF-8原來恰好能跑的代碼就暴露了問題。下載場景里常見的是Content-Disposition只寫了filename沒有按規(guī)范補filename*。解決統(tǒng)一全鏈路 UTF-8包括文件系統(tǒng)、應用配置、響應頭、數(shù)據庫連接。下載接口按規(guī)范同時輸出filename和filename*兩個參數(shù)兼容舊客戶端。URL 里的中文參數(shù)在代理層不要做二次編碼Nginx 默認會對 URI 做一次解碼配置里如果開了二次解碼反而會亂。5.5 WebSocket 和長連接在代理后面連不上現(xiàn)象實時推送功能在測試環(huán)境正常切換后一直 502 或者連接幾秒就斷。原因WebSocket 需要Upgrade和Connection兩個頭透傳Nginx 默認不透傳這兩項另外長連接的空閑超時默認值偏短連接被代理主動斷掉。如果用了平滑重載工作進程退出時也會把長連接一起切斷。解決代理的 location 里顯式加proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection upgrade把proxy_read_timeout調到業(yè)務能接受的范圍。重載時設置工作進程的優(yōu)雅退出時間讓存量連接自然結束再退出。切換前一定要單獨測一遍實時功能這類問題不會在普通頁面上暴露出來。6. 按場景落地三個答案加一條驗證命令把上面的內容收成三個可執(zhí)行的判斷你對號入座就行。你的場景推薦方案核心理由站點多、證書雜、運維人手少Caddy 獨立承接證書自動簽發(fā)續(xù)期配置量最小以靜態(tài)資源和反向代理為主團隊熟悉主流方案Nginx 獨立承接資料多、招人容易、調優(yōu)空間大純 .NET 服務追求部署簡單Kestrel 加 Nginx 或 Caddy 前置應用與服務器職責分離升級只重啟進程依賴 Windows 組件或經典 ASP保留 Windows 主機入口層換反向代理硬遷成本遠高于分層過渡定完方案之后別急著切流量先跑一條最樸素的驗證命令。下面這段用 curl 把整條鏈路的關鍵行為一次性驗一遍包括大文件上傳、轉發(fā)頭、錯誤頁返回碼。# 1. 大文件上傳驗證請求體限制是否放開構造 50MB 隨機文件 head -c 52428800 /dev/urandom /tmp/probe.bin curl -s -o /dev/null -w upload:%{http_code}\n \ -F file/tmp/probe.bin https://app.internal.example/api/upload # 2. 轉發(fā)頭確認后端拿到的客戶端地址不是 127.0.0.1 curl -s https://app.internal.example/api/whoami # 3. 深層鏈接確認 SPA 回退規(guī)則生效返回 200 而不是 404 curl -s -o /dev/null -w spa:%{http_code}\n \ https://app.internal.example/some/deep/route # 4. 錯誤頁請求不存在的接口確認返回碼和自定義頁都符合預期 curl -s -o /dev/null -w error:%{http_code}\n \ https://app.internal.example/api/not-exist四個檢查項分別對應四類最容易出問題的地方。第一項失敗說明請求體限制沒改全第二項失敗說明轉發(fā)頭鏈路斷了第三項失敗說明重寫或回退規(guī)則翻錯了第四項失敗多半是錯誤頁配置把返回碼一并改成了 200而返回碼被改寫會直接影響監(jiān)控告警和搜索引擎行為比頁面顯示錯誤更隱蔽。說實話我最早做這類遷移時吃過最大的虧不是技術選型選錯而是沒把「原環(huán)境到底依賴了什么」當回事。那次上傳翻車之后我給自己定了個死規(guī)矩不管站點多小動手前必須把 web.config 從頭到尾讀一遍把每一條限制、每一條重寫規(guī)則都抄到一張表上逐條標注在新環(huán)境怎么落地。這個動作看著笨但它把不確定性從切換當天才發(fā)現(xiàn)挪到了動手之前就清楚后面所有事都輕松了。希望這些踩坑記錄能幫你少走一段彎路。本文還有配套的精品資源點擊獲取