當(dāng)你負(fù)責(zé)的web服務(wù)因一臺(tái)ECS異常離線，用戶端的報(bào)錯(cuò)往往不是“某臺(tái)服務(wù)器故障”，而是成片的502/504。這種大面積業(yè)務(wù)中斷的背后，大概率是負(fù)載均衡的健康檢查機(jī)制在起作用?？焖俣ㄎ徊⑿迯?fù)阿里云SLB健康檢查異常排查中的關(guān)鍵節(jié)點(diǎn)，是恢復(fù)服務(wù)的第一道門(mén)檻。

一、認(rèn)識(shí)SLB健康檢查：原理與異常影響

SLB健康檢查本質(zhì)上是負(fù)載均衡對(duì)后端ECS服務(wù)可用性的自動(dòng)化驗(yàn)證。它通過(guò)內(nèi)網(wǎng)地址定期發(fā)送探測(cè)請(qǐng)求，源IP固定來(lái)自100.64.0.0/10網(wǎng)段，根據(jù)后端返回的響應(yīng)碼或連接狀態(tài)，判斷服務(wù)器是否正常服務(wù)。一旦探測(cè)失敗，SLB會(huì)立即停止向該節(jié)點(diǎn)分發(fā)流量，避免請(qǐng)求積壓和雪崩效應(yīng)。

這個(gè)機(jī)制看似簡(jiǎn)單，但在實(shí)際運(yùn)維中卻常常成為排障盲區(qū)。多數(shù)人理解健康檢查只是“看看機(jī)器死沒(méi)死”，事實(shí)上TCP、HTTP、HTTPS三種探測(cè)方式的判定邏輯差異很大——TCP只看三次握手是否完成，HTTP要求返回2xx/3xx狀態(tài)碼，HTTPS則還需校驗(yàn)證書(shū)有效性。一個(gè)應(yīng)用層返回401的URL，就能讓整臺(tái)ECS被踢出集群。

1. 異常表現(xiàn)如何穿透到用戶側(cè)

健康檢查異常的直接后果是用戶請(qǐng)求被轉(zhuǎn)發(fā)到剩余健康節(jié)點(diǎn)。如果集群規(guī)模小或者異常ECS比例過(guò)高，流量?jī)A斜會(huì)瞬間壓垮其他服務(wù)器，用戶在瀏覽器端看到的典型表現(xiàn)就是502 Bad Gateway或504 Gateway Timeout錯(cuò)誤。

很多時(shí)候運(yùn)維人員的第一反應(yīng)是排查應(yīng)用日志，但忽略了SLB控制臺(tái)的后端服務(wù)器健康狀態(tài)。事實(shí)上，阿里云控制臺(tái)會(huì)明確標(biāo)示每個(gè)監(jiān)聽(tīng)下哪臺(tái)ECS處于異常狀態(tài)，以及最后一次健康檢查失敗的原因簡(jiǎn)述。這個(gè)信息入口比盲查應(yīng)用日志高效得多，可惜不少團(tuán)隊(duì)沒(méi)養(yǎng)成先看控制臺(tái)的習(xí)慣。

2. 業(yè)務(wù)連續(xù)性在幾秒內(nèi)被打破

當(dāng)健康檢查閾值設(shè)置得過(guò)于激進(jìn)，比如連續(xù)2次失敗就摘除節(jié)點(diǎn)，配合3秒一次的探測(cè)間隔，意味著一個(gè)瞬時(shí)網(wǎng)絡(luò)抖動(dòng)只需6秒就能讓ECS離線。對(duì)于每天處理數(shù)十萬(wàn)訂單的電商系統(tǒng)，6秒的中斷足以造成直接營(yíng)收損失。

這還不是最麻煩的。中小團(tuán)隊(duì)通常缺少專職運(yùn)維，從發(fā)現(xiàn)問(wèn)題、定位到恢復(fù)，動(dòng)輒半小時(shí)以上。云服務(wù)器、數(shù)據(jù)庫(kù)、CDN等多套資源分散在不同廠商，排查時(shí)需要來(lái)回切換控制臺(tái)、核對(duì)配置，溝通成本極高。缺少專職運(yùn)維的中小團(tuán)隊(duì)，想要云服務(wù)器、數(shù)據(jù)庫(kù)、CDN資源統(tǒng)一搭建落地，可以參考聚搜云這類一站式云服務(wù)方案，減少多廠商對(duì)接的繁瑣成本，把精力真正聚焦在應(yīng)用層的健康檢查策略調(diào)優(yōu)上。

二、健康檢查異?？焖僭\斷流程

大多數(shù)業(yè)務(wù)中斷告警的背后，第一落點(diǎn)往往是 SLB 健康檢查異常。對(duì)運(yùn)維資源有限的團(tuán)隊(duì)來(lái)說(shuō)，即便知道問(wèn)題出在“端口→網(wǎng)絡(luò)→應(yīng)用”這條鏈路上，也容易在阿里云控制臺(tái)、安全組、系統(tǒng)防火墻、應(yīng)用日志之間反復(fù)橫跳，拉長(zhǎng)排障時(shí)間。缺少專職運(yùn)維的中小團(tuán)隊(duì)，想要云服務(wù)器、數(shù)據(jù)庫(kù)、CDN 資源統(tǒng)一搭建落地，可以參考聚搜云這類一站式云服務(wù)方案，減少多廠商對(duì)接的繁瑣成本，讓健康檢查這類高頻問(wèn)題不再依賴個(gè)人經(jīng)驗(yàn)，而是有一套可復(fù)用的排查基線。

1. 如何查看健康檢查狀態(tài)

健康檢查的“異?！辈⒉皇且粋€(gè)模糊的結(jié)論，阿里云 SLB 控制臺(tái)實(shí)際上給出了分層信號(hào)，關(guān)鍵在于會(huì)看、會(huì)串起來(lái)。

• 監(jiān)聽(tīng)維度：在實(shí)例詳情的監(jiān)聽(tīng)頁(yè)，直接可見(jiàn)每個(gè)監(jiān)聽(tīng)的健康檢查狀態(tài)概覽，正常/異常以綠色/紅色標(biāo)識(shí)。點(diǎn)進(jìn)監(jiān)聽(tīng)后，“后端服務(wù)器”頁(yè)會(huì)精確到每臺(tái) ECS 的健康檢查失敗次數(shù)和原因提示，例如“超時(shí)”“連接失敗”“HTTP 碼不匹配”等。

• 云監(jiān)控聯(lián)動(dòng)：在“云監(jiān)控”中為“七層監(jiān)聽(tīng)健康檢查異?！焙汀八膶颖O(jiān)聽(tīng)健康檢查異?！痹O(shè)置報(bào)警規(guī)則，能第一時(shí)間收到異常后端服務(wù)器數(shù)量變化的通知，而不是等到用戶報(bào)障。

• 快速定位異常范圍：如果某監(jiān)聽(tīng)下所有后端一起變紅，優(yōu)先檢查 SLB 監(jiān)聽(tīng)配置（端口、健康檢查 URL、超時(shí)時(shí)間）是否與后端一致；僅單臺(tái)異常，則幾乎可以壓到那臺(tái) ECS 自身上。

很多工程師到這一步就急著去重啟應(yīng)用，實(shí)際還有一個(gè)關(guān)鍵動(dòng)作：先記錄異常出現(xiàn)時(shí)間點(diǎn)，與 ECS 系統(tǒng)日志、應(yīng)用日志做時(shí)間對(duì)齊，再動(dòng)手，否則證據(jù)鏈容易斷掉。

2. 必備排查工具介紹

排查不是靠猜，而是分層驗(yàn)證工具的組合。常用的 ping、telnet、curl、strace 各有明確的分工，對(duì)應(yīng)著“端口→網(wǎng)絡(luò)→應(yīng)用”三層。

• 端口層驗(yàn)證：從同一 VPC 內(nèi)其他 ECS 上執(zhí)行 telnet<健康檢查端口>，能快速判斷目標(biāo)端口是否可通。不通時(shí)，典型需核對(duì)兩個(gè)地方：阿里云安全組入方向是否允許 100.64.0.0/10 源地址訪問(wèn)該端口，以及 ECS 內(nèi)部的系統(tǒng)防火墻（iptables/firewalld）是否也放行。經(jīng)驗(yàn)上，端口不通的案例里，幾乎一半是只查了安全組忘了系統(tǒng)防火墻。

• 應(yīng)用層驗(yàn)證：curl -Iv http://<內(nèi)網(wǎng)ip>:<端口>/<健康檢查路徑> 是模擬 SLB HTTP 探測(cè)的最直接手段。重點(diǎn)看返回值：2xx/3xx 才是健康檢查認(rèn)可的狀態(tài)碼，401/403 往往意味著健康檢查 URL 要求登錄鑒權(quán)，需要調(diào)整路徑。如果返回 504 或者連接被拒，說(shuō)明應(yīng)用處理卡頓或未監(jiān)聽(tīng)在正確地址（0.0.0.0 而非 127.0.0.1）。

• 超時(shí)原因深挖：當(dāng)異常提示“響應(yīng)超時(shí)”，但 curl 偶爾能通或響應(yīng)慢，可以用 strace -p <進(jìn)程pid> 跟蹤業(yè)務(wù)進(jìn)程的系統(tǒng)調(diào)用堆棧，觀察是卡在磁盤(pán) I/O、外部數(shù)據(jù)庫(kù)連接還是鎖等待。這一步能避免盲目調(diào)大超時(shí)閾值掩蓋底層瓶頸。

把這三類工具配合使用，可以覆蓋九成以上的健康檢查異常場(chǎng)景，且不需要進(jìn)入生產(chǎn)環(huán)境瞎試。記錄指令結(jié)果、截圖存檔，逐漸形成自己團(tuán)隊(duì)的標(biāo)準(zhǔn)排查操作卡，下次告警來(lái)臨時(shí)，一線同事就能按步驟獨(dú)立定位。

三、端口配置排查：從監(jiān)聽(tīng)端口到安全組

健康檢查異常的根因中，端口不通是最直接、占比最高的故障點(diǎn)。工程師容易陷入一個(gè)誤區(qū)——看到后端ECS標(biāo)記為“異常”就下意識(shí)認(rèn)為是應(yīng)用宕機(jī)，實(shí)際上多數(shù)情況只是某個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)沒(méi)有放行健康檢查流量。這里的排查不需要復(fù)雜的抓包分析，但必須嚴(yán)格遵循“監(jiān)聽(tīng)端口 → 安全組 → 系統(tǒng)防火墻”的鏈路，逐層確認(rèn)每一跳的連通性。

1. 監(jiān)聽(tīng)端口配置自檢

先用一筆簡(jiǎn)單事實(shí)對(duì)齊認(rèn)知：SLB健康檢查報(bào)文全部走內(nèi)網(wǎng)，源地址屬于 100.64.0.0/10 網(wǎng)段，探測(cè)目標(biāo)就是后端ECS上配置的健康檢查端口。因此，第一步不是查安全組，而是確認(rèn)這個(gè)端口到底有沒(méi)有在監(jiān)聽(tīng)正確的地址。

• 排查命令：登錄ECS執(zhí)行 ss -tlnp | grep <健康檢查端口> 或 netstat -tlnp，重點(diǎn)觀察 Local Address 列。如果顯示為 127.0.0.1:端口，意味著服務(wù)只綁定了回環(huán)地址，SLB的內(nèi)網(wǎng)探測(cè)包會(huì)被直接丟棄。必須調(diào)整為 0.0.0.0 或具體的內(nèi)網(wǎng)IP。

• TCP與HTTP檢查的差別：TCP健康檢查只需完成三次握手，端口監(jiān)聽(tīng)就視為成功；HTTP/HTTPS檢查則要求返回 2xx/3xx 狀態(tài)碼。很多排查者發(fā)現(xiàn)端口已監(jiān)聽(tīng)就認(rèn)為配置無(wú)誤，卻忽略了HTTP檢查下健康檢查URL的響應(yīng)碼。如果應(yīng)用對(duì)該URL啟用了登錄鑒權(quán)、攔截器，返回 401/403，SLB同樣判定為異常。建議為健康檢查單獨(dú)設(shè)計(jì)一個(gè)無(wú)需認(rèn)證的探活路徑（如 /health），返回 200 OK 即可。

• UDP檢查的特殊性：UDP無(wú)連接特性使得端口監(jiān)聽(tīng)無(wú)法直接驗(yàn)證。UD P監(jiān)聽(tīng)的健康檢查依賴ICMP或自定義UDP報(bào)文，此時(shí)務(wù)必確認(rèn)應(yīng)用能夠處理SLB發(fā)送的特定探測(cè)字符串，否則會(huì)被誤判為失敗。

2. 安全組規(guī)則精細(xì)核查要點(diǎn)

確認(rèn)端口在正確地址上監(jiān)聽(tīng)后，下一步鎖定安全組。阿里云SLB健康檢查流量首先經(jīng)過(guò)安全組過(guò)濾，這是云上最容易被遺漏的地方。

• 方向決定成敗：很多人只查了ECS出方向（Egress）規(guī)則，但健康檢查流量是入方向（Ingress）。在安全組規(guī)則界面，務(wù)必切換到“入方向”，并確認(rèn)健康檢查端口已在允許列表中。

• 源地址必須精確匹配：允許的源IP不能隨手填一個(gè)內(nèi)網(wǎng)段，而必須覆蓋 100.64.0.0/10。實(shí)踐中更穩(wěn)妥的做法是直接引用SLB所屬的安全組作為授權(quán)對(duì)象，但這種配置只有同地域內(nèi)網(wǎng)互通時(shí)可行；跨地域或混合云架構(gòu)下，必須顯式填入 100.64.0.0/10 網(wǎng)段，并開(kāi)放健康檢查端口。

• 快速驗(yàn)證技巧：利用同一VPC內(nèi)另一臺(tái)ECS執(zhí)行 telnet <目標(biāo)ecs內(nèi)網(wǎng)ip> <健康檢查端口>。假如telnet成功，說(shuō)明鏈路是通的；不通則幾乎可以定位為安全組或系統(tǒng)防火墻問(wèn)題。切忌從辦公網(wǎng)直接telnet云上ECS，因?yàn)楣性七吔绮呗酝ǔ?huì)攔截這類直接探測(cè)。

3. 系統(tǒng)防火墻排查：往往被忽略的最后一關(guān)

安全組放行后流量到達(dá)ECS內(nèi)部，還要面對(duì)系統(tǒng)自帶的包過(guò)濾——如iptables、firewalld或Windows防火墻。這是典型的“只查安全組不查系統(tǒng)防火墻”的疏漏區(qū)。

• Linux環(huán)境：直接執(zhí)行 iptables -L -n 查看INPUT鏈規(guī)則，關(guān)注是否有針對(duì)健康檢查端口的REJECT或DROP。常見(jiàn)錯(cuò)誤是早期運(yùn)維添加了臨時(shí)規(guī)則未清除。如果使用firewalld，則通過(guò) firewall-cmd --list-all 檢查當(dāng)前zone服務(wù)或端口放行策略。對(duì)于已配置的規(guī)則，可以通過(guò)插入臨時(shí)日志命令來(lái)確認(rèn)是否有健康檢查來(lái)源的包被丟棄，例如：iptables -I INPUT 1 -s 100.64.0.0/10 -j LOG --log-prefix "SLB_CHECK: "，然后查看 dmesg 或 /var/log/messages。

• Windows Server環(huán)境：進(jìn)入“高級(jí)安全Windows Defender防火墻”，驗(yàn)證入站規(guī)則中是否有一條允許 100.64.0.0/10 網(wǎng)段訪問(wèn)健康檢查端口的規(guī)則，且規(guī)則優(yōu)先級(jí)未被其他拒絕規(guī)則覆蓋。

• 三層檢查清單中的端口級(jí)閉環(huán)：完成以上排查后，端口層的三個(gè)節(jié)點(diǎn)就形成了閉環(huán)。此時(shí)若問(wèn)題依舊，就有底氣將疑點(diǎn)轉(zhuǎn)向網(wǎng)絡(luò)路由或應(yīng)用健康檢查邏輯，而不是在端口層反復(fù)徘徊。快速排障的紀(jì)律永遠(yuǎn)是：先證明端口可達(dá)，再質(zhì)疑應(yīng)用狀態(tài)。

四、網(wǎng)絡(luò)連通性檢查：確保SLB至ECS鏈路順暢

健康檢查異常的一大類根因并不在ECS本機(jī)，而是在中間的網(wǎng)絡(luò)上。即使后端服務(wù)器上的應(yīng)用正常監(jiān)聽(tīng)了端口，安全組規(guī)則也已放行，依然可能因?yàn)閂PC路由、子網(wǎng)網(wǎng)關(guān)或跨域鏈路的問(wèn)題，導(dǎo)致SLB探活報(bào)文無(wú)法送達(dá)。排查網(wǎng)絡(luò)層時(shí)，必須明確一個(gè)前提：阿里云SLB的健康檢查探測(cè)報(bào)文全部通過(guò)內(nèi)網(wǎng)發(fā)出，源IP來(lái)自100.64.0.0/10網(wǎng)段，這意味著所有測(cè)試都必須基于后端服務(wù)器的內(nèi)網(wǎng)地址進(jìn)行，公網(wǎng)連通性與此無(wú)關(guān)。

1. 用ping與telnet做端口與連通性的快速分診

網(wǎng)絡(luò)層排查的第一步永遠(yuǎn)是驗(yàn)證“可達(dá)性”。從同一VPC內(nèi)的任意一臺(tái)ECS上執(zhí)行ping <目標(biāo)ecs內(nèi)網(wǎng)ip>，可以快速判斷兩臺(tái)機(jī)器間的三層路由是否正常。但僅有ICMP暢通還不夠，健康檢查大概率使用TCP或HTTP協(xié)議，必須進(jìn)一步驗(yàn)證四層端口。用telnet <目標(biāo)內(nèi)網(wǎng)ip> <健康檢查端口>是最直接的手段——如果連接立即建立（Connected），說(shuō)明端口可達(dá)且路徑上安全組和系統(tǒng)防火墻均未阻斷；如果長(zhǎng)時(shí)間無(wú)響應(yīng)或直接Connection refused，則大概率存在防火墻阻攔或服務(wù)未監(jiān)聽(tīng)。

需要注意，Connection refused通常意味著端口根本沒(méi)有在監(jiān)聽(tīng)，而連接超時(shí)（timeout）則更多指向網(wǎng)絡(luò)中間設(shè)備丟棄了SYN包。如果telnet測(cè)試通但健康檢查仍異常，往往需要懷疑安全組的規(guī)則方向：SLB發(fā)出的探測(cè)地址是100.64.0.0/10，很多團(tuán)隊(duì)在安全組入方向只放行了業(yè)務(wù)客戶端IP段或辦公出口IP，忽略了這一內(nèi)網(wǎng)探測(cè)源，導(dǎo)致流量直接被丟棄。因此，排查時(shí)應(yīng)將100.64.0.0/10顯式加入安全組白名單，并確認(rèn)規(guī)則優(yōu)先級(jí)未被其他DENY規(guī)則覆蓋。

2. VPC路由表、對(duì)端網(wǎng)關(guān)與跨地域鏈路備忘

當(dāng)端口層和安全組確認(rèn)無(wú)誤，但健康檢查依然間歇性或持續(xù)失敗時(shí)，需要進(jìn)入路由層面的排查。對(duì)于單VPC內(nèi)部的簡(jiǎn)單部署，通常默認(rèn)路由即可投遞，但如果使用了VPC對(duì)等連接、云企業(yè)網(wǎng)（CEN）或?qū)＞€，將有至后端服務(wù)器的自定義路由條目，就必須檢查路由表的下一跳是否指向正確的目標(biāo)。典型故障包括：路由目標(biāo)網(wǎng)段未包含健康檢查源IP所在的100.64.0.0/10，導(dǎo)致回程報(bào)文走默認(rèn)路由被丟棄；或者對(duì)端VPC的網(wǎng)關(guān)設(shè)備做了源地址過(guò)濾，未放行該預(yù)留網(wǎng)段。

跨地域的場(chǎng)景更值得警惕。例如SLB實(shí)例在華北地域，后端部分ECS位于華東，通過(guò)云企業(yè)網(wǎng)打通。此時(shí)健康檢查報(bào)文需要穿越跨地域鏈路，延遲和丟包率都會(huì)上升。如果健康檢查超時(shí)時(shí)間設(shè)置得過(guò)于嚴(yán)格（如2秒），而跨域RTT已接近閾值，就會(huì)產(chǎn)生假異常。實(shí)際處置中，我們建議將跨地域后端服務(wù)器的健康檢查超時(shí)時(shí)間至少調(diào)整為5秒以上，并適當(dāng)提高不健康閾值，避免因網(wǎng)絡(luò)抖動(dòng)造成頻繁剔除與加入。

此外，如果后端服務(wù)器上配置了多網(wǎng)卡或多路由表（例如作為VPN網(wǎng)關(guān)或中轉(zhuǎn)代理），默認(rèn)路由可能不會(huì)將回程流量送回SLB探測(cè)源，此時(shí)需要配置源策略路由，確保來(lái)自100.64.0.0/10的流量原路返回。排查時(shí)可以在ECS內(nèi)部抓包：tcpdump -i eth0 src net 100.64.0.0/10，觀察是否收到SYN包，以及是否有RST或未回SYN-ACK的情況。若只收到SYN而無(wú)響應(yīng)，則多半是系統(tǒng)防火墻或內(nèi)核路由問(wèn)題，而非單純網(wǎng)絡(luò)不通。

總的來(lái)說(shuō)，網(wǎng)絡(luò)連通性排查的本質(zhì)是沿著SLB到ECS的報(bào)文路徑逐跳驗(yàn)證。無(wú)論是簡(jiǎn)單的安全組遺漏，還是隱蔽的路由策略錯(cuò)誤，都能通過(guò)從內(nèi)網(wǎng)ping、telnet到抓包的分層手段快速定位。牢記100.64.0.0/10這個(gè)探測(cè)源網(wǎng)段，并把它作為固定檢查項(xiàng)寫(xiě)進(jìn)網(wǎng)絡(luò)層清單，可以避免半數(shù)以上的網(wǎng)絡(luò)層誤判。

五、應(yīng)用健康狀態(tài)驗(yàn)證：服務(wù)進(jìn)程與響應(yīng)

應(yīng)用層的健康檢查失敗，往往在“端口通、網(wǎng)絡(luò)通”之后才暴露出來(lái)——這時(shí)問(wèn)題焦點(diǎn)轉(zhuǎn)移至服務(wù)進(jìn)程本身是否正常、健康檢查URL返回的狀態(tài)碼是否符合預(yù)期，以及響應(yīng)時(shí)間是否超出了SLB的超時(shí)閾值。這三類原因在實(shí)際排障中占比極高，但被“端口不通”掩蓋的情況也最多，務(wù)必先完成端口和網(wǎng)絡(luò)的確認(rèn)再進(jìn)入應(yīng)用層分析。

1. 服務(wù)進(jìn)程是否運(yùn)行

并不能因?yàn)?code>ps aux | grep看到進(jìn)程存在就認(rèn)為服務(wù)正常。真正有效的驗(yàn)證是：進(jìn)程正在監(jiān)聽(tīng)的地址和端口與健康檢查配置完全匹配。很多應(yīng)用默認(rèn)監(jiān)聽(tīng)127.0.0.1，而SLB健康檢查通過(guò)內(nèi)網(wǎng)地址發(fā)起的請(qǐng)求實(shí)際上是訪問(wèn)ECS的私有IP，如果進(jìn)程未監(jiān)聽(tīng)0.0.0.0或ECS的內(nèi)網(wǎng)IP，就會(huì)出現(xiàn)“進(jìn)程活著但健康檢查失敗”的典型誤判。

排查時(shí)優(yōu)先執(zhí)行netstat -tlnp | grep <端口>，確認(rèn)Local Address一列是0.0.0.0:端口或內(nèi)網(wǎng)IP:端口。若發(fā)現(xiàn)僅監(jiān)聽(tīng)127.0.0.1，需修改應(yīng)用配置（如Nginx的listen指令、Gunicorn的-b參數(shù)）并重啟服務(wù)。對(duì)于多進(jìn)程或容器化部署，可用ss -lntp確認(rèn)每個(gè)工作進(jìn)程的實(shí)際監(jiān)聽(tīng)狀態(tài)，避免因主進(jìn)程存活但子進(jìn)程已僵死導(dǎo)致的假正常。這一層如果查不出問(wèn)題，再轉(zhuǎn)向URL返回碼與超時(shí)。

2. 健康檢查URL返回碼解讀

SLB HTTP/HTTPS健康檢查將2xx和3xx狀態(tài)碼視為成功，其余一律視為失敗，這是一個(gè)剛性規(guī)則。常見(jiàn)誤區(qū)是隨意設(shè)一個(gè)首頁(yè)路徑，但該頁(yè)面可能重定向到需要登錄的地址返回302后又要求認(rèn)證返回401/403，或者某些API路徑只接受POST請(qǐng)求而SLB發(fā)包是GET，直接返回405 Method Not Allowed。此類非2xx/3xx的響應(yīng)碼會(huì)導(dǎo)致后端直接標(biāo)記為不健康。

快速驗(yàn)證命令：從同一VPC內(nèi)的另一臺(tái)ECS執(zhí)行curl -Iv http://<目標(biāo)ecs內(nèi)網(wǎng)ip>:<端口>/<健康檢查路徑>，重點(diǎn)關(guān)注返回的HTTP狀態(tài)碼及響應(yīng)頭。如果看到401 Unauthorized，就說(shuō)明健康檢查URL綁定了認(rèn)證邏輯，應(yīng)更換為無(wú)需鑒權(quán)的獨(dú)立探活端點(diǎn)（如/health），該端點(diǎn)內(nèi)部可包含輕量級(jí)的數(shù)據(jù)庫(kù)/緩存連通性檢查，但本身不應(yīng)依賴會(huì)話。若返回404或405，需與開(kāi)發(fā)團(tuán)隊(duì)對(duì)齊全路徑和方法，確保SLB配置的路徑與后端實(shí)際路由一致。

如果必須保留原有認(rèn)證頁(yè)面又想通過(guò)健康檢查，可在Nginx中利用location對(duì)健康檢查URL做剝離：將該URI直接返回200狀態(tài)碼并忽略后續(xù)邏輯。典型的配置片段為：

location = /health {
    access_log off;
    return 200 'ok';
}

這種對(duì)健康檢查URL“旁路處理”的方式，是避免應(yīng)用邏輯干擾探活的有效手段。

3. 應(yīng)用響應(yīng)超時(shí)分析

超時(shí)導(dǎo)致的健康檢查異常更像一種“軟故障”——端口通、進(jìn)程在、URL也能最后返回200，但首包時(shí)間超過(guò)了SLB設(shè)置的健康檢查超時(shí)時(shí)間。默認(rèn)超時(shí)通常在5秒左右，若應(yīng)用因線程池耗盡、數(shù)據(jù)庫(kù)連接池滿或外部API調(diào)用卡頓而響應(yīng)緩慢，就很容易被SLB判定為超時(shí)并摘除后端。

排查時(shí)仍用curl -w輸出時(shí)間消耗明細(xì)：curl -o /dev/null -s -w "time_namelookup:%{time_namelookup}\ntime_connect:%{time_connect}\ntime_starttransfer:%{time_starttransfer}\ntime_total:%{time_total}\n" http://內(nèi)網(wǎng)IP:端口/健康檢查路徑。重點(diǎn)關(guān)注time_starttransfer（首字節(jié)時(shí)間），若該值持續(xù)接近或超過(guò)健康檢查超時(shí)閾值，說(shuō)明應(yīng)用處理環(huán)節(jié)存在瓶頸。此時(shí)可用strace -p跟蹤Nginx或Java進(jìn)程的系統(tǒng)調(diào)用，看是否卡在epoll_wait或futex，也可結(jié)合應(yīng)用自身的訪問(wèn)日志和APM工具，定位具體慢在哪一個(gè)下游依賴上。

若因業(yè)務(wù)冷啟動(dòng)或滾動(dòng)發(fā)布導(dǎo)致短期內(nèi)響應(yīng)變慢，不應(yīng)簡(jiǎn)單地調(diào)大超時(shí)時(shí)間了事，而應(yīng)結(jié)合SLB的“健康閾值”與“不健康閾值”來(lái)平滑狀態(tài)切換。例如將不健康閾值從默認(rèn)的3次提升到5次，避免因單次瞬時(shí)抖動(dòng)就剔除實(shí)例；同時(shí)避免將健康檢查間隔設(shè)得太短（如小于2秒），否則高頻探活會(huì)在系統(tǒng)負(fù)載略高時(shí)產(chǎn)生多米諾效應(yīng)。這些參數(shù)的調(diào)優(yōu)沒(méi)有通用數(shù)值，需要在業(yè)務(wù)壓測(cè)中驗(yàn)證當(dāng)前配置的容錯(cuò)邊界。

六、優(yōu)化健康檢查策略與長(zhǎng)期預(yù)防

把健康檢查當(dāng)作一次性配置丟在一邊，是運(yùn)維里最隱蔽的風(fēng)險(xiǎn)——它往往在凌晨的業(yè)務(wù)低谷被觸發(fā)，然后被忽略，直到下一次發(fā)布或事故時(shí)才炸開(kāi)。

1. 健康檢查參數(shù)怎么調(diào)，才不會(huì)反過(guò)來(lái)坑自己

健康檢查參數(shù)沒(méi)有標(biāo)準(zhǔn)答案，但有一條鐵律：必須比應(yīng)用真實(shí)的啟動(dòng)與優(yōu)雅停機(jī)時(shí)間長(zhǎng)，同時(shí)又能真實(shí)反映服務(wù)就緒狀態(tài)。

常見(jiàn)的踩坑場(chǎng)景是：應(yīng)用啟動(dòng)需要 20 秒，健康檢查超時(shí)卻只設(shè) 2 秒、間隔 3 秒，連續(xù)失敗 2 次就摘除。結(jié)果每次滾動(dòng)發(fā)布，還沒(méi)來(lái)得及完成初始化的新節(jié)點(diǎn)就被 SLB 判定異常，流量直接被切斷，發(fā)布窗口變得像走鋼絲。正確的做法是把這些數(shù)值拉寬：超時(shí)時(shí)間至少設(shè)為應(yīng)用最大啟動(dòng)延遲的 1.5 倍，不健康閾值不要低于 3 次，健康閾值也建議保持 3 次以上，讓“上線”與“摘除”狀態(tài)切換變得平滑，避免瞬時(shí)抖動(dòng)導(dǎo)致的誤剔除。

HTTP 健康檢查的另一個(gè)常見(jiàn)坑是 URL 選擇不當(dāng)。很多人隨便填個(gè) “/” 就上線，結(jié)果這個(gè)首頁(yè)路徑依賴數(shù)據(jù)庫(kù)連接或 Redis，一旦依賴抖動(dòng)，健康檢查也跟著失敗，進(jìn)而引發(fā)雪崩。健康檢查路徑應(yīng)該是一個(gè)輕量獨(dú)立的探活端點(diǎn)，比如 /healthz，只驗(yàn)證進(jìn)程存活性與最基本依賴（如文件句柄），不觸發(fā)外部調(diào)用，返回 200 即可。如果應(yīng)用框架自帶健康端點(diǎn)（如 Spring Boot Actuator），更要抽出一個(gè)“無(wú)副作用”的子路徑來(lái)配合 SLB 的檢查，避免把全量健康檢查暴露給負(fù)載均衡——那會(huì)把一次 GC 停頓放大成節(jié)點(diǎn)被錯(cuò)誤摘除。

2. 配置監(jiān)控與告警，讓異常在擴(kuò)大前被發(fā)現(xiàn)

健康檢查失敗的量變到質(zhì)變，通常有跡可循。云監(jiān)控里可以配置“健康檢查異常后端實(shí)例數(shù)”大于 0 的報(bào)警，但這只是最低保障。真正有效的策略是疊加兩個(gè)維度的告警：

• 數(shù)量維度：異常實(shí)例數(shù)超過(guò)總體的 30% 且持續(xù) 1 分鐘以上才告警，避免單節(jié)點(diǎn)短暫閃斷帶來(lái)的噪音。

• 時(shí)間維度：統(tǒng)計(jì)每分鐘異常狀態(tài)總計(jì)時(shí)長(zhǎng)，超過(guò) 30 秒觸發(fā)預(yù)警，提前介入。

同時(shí)，不要只盯著 SLB 面板。在后端服務(wù)器上，部署一個(gè)定時(shí)腳本，從同 VPC 內(nèi)的一臺(tái) ECS 上模擬健康檢查請(qǐng)求，把結(jié)果與 SLB 的健康檢查狀態(tài)做交叉驗(yàn)證。如果兩者同時(shí)失敗，就是應(yīng)用層或系統(tǒng)層的硬傷；如果只有 SLB 判定異常而本地探測(cè)正常，問(wèn)題多半卡在網(wǎng)絡(luò)路徑上（安全組、系統(tǒng)防火墻、路由表），這個(gè)差異能極大縮短排查定位時(shí)間。

3. 定期巡檢不是“有空才做”，而是寫(xiě)進(jìn)運(yùn)維日歷的強(qiáng)制動(dòng)作

依賴告警是被動(dòng)響應(yīng)，依賴巡檢才是主動(dòng)預(yù)防。建議把以下動(dòng)作固化成周級(jí)巡檢清單：

第一，遍歷所有 SLB 監(jiān)聽(tīng)的后端服務(wù)器健康狀態(tài)，拉出最近 7 天內(nèi)異常時(shí)長(zhǎng)超過(guò) 60 秒的節(jié)點(diǎn)，逐一確認(rèn)異常原因是否已閉環(huán)——大量的偶發(fā)異常會(huì)因?yàn)椤白詣?dòng)恢復(fù)”而被遺忘，但下一次可能就是持續(xù)性故障。

第二，檢查安全組與系統(tǒng)防火墻規(guī)則的有效性。變更管理混亂時(shí)，某次臨時(shí)放通測(cè)試后忘了回滾，或者防火墻規(guī)則莫名其妙被 systemd 服務(wù)覆蓋，是造成“之前好好的突然不通”的頭號(hào)元兇。用 iptables -L -n 或 firewall-cmd --list-all 對(duì)比基線文檔，能擋住不少低級(jí)故障。

第三，做一次健康檢查端口的“盲測(cè)”：從 SLB 的視角用 telnet 或 curl 驗(yàn)證所有后端端口，確認(rèn)沒(méi)有因證書(shū)過(guò)期、DNS 解析變更、應(yīng)用監(jiān)聽(tīng)地址綁定為 127.0.0.1 導(dǎo)致的本地可用但遠(yuǎn)端不可達(dá)。

穩(wěn)健的健康檢查不是調(diào)參調(diào)出來(lái)的，而是靠策略優(yōu)化、持續(xù)監(jiān)控和定期巡檢一起撐起來(lái)的。把這三件事做成例行公事，遠(yuǎn)比每次故障后加班翻日志要?jiǎng)澦恪?/p>