當你負責的web服務因一臺ECS異常離線，用戶端的報錯往往不是“某臺服務器故障”，而是成片的502/504。這種大面積業(yè)務中斷的背后，大概率是負載均衡的健康檢查機制在起作用。快速定位并修復阿里云SLB健康檢查異常排查中的關(guān)鍵節(jié)點，是恢復服務的第一道門檻。

一、認識SLB健康檢查：原理與異常影響

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

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

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

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

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

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

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

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

二、健康檢查異常快速診斷流程

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

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

健康檢查的“異常”并不是一個模糊的結(jié)論，阿里云 SLB 控制臺實際上給出了分層信號，關(guān)鍵在于會看、會串起來。

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

• 云監(jiān)控聯(lián)動：在“云監(jiān)控”中為“七層監(jiān)聽健康檢查異常”和“四層監(jiān)聽健康檢查異常”設置報警規(guī)則，能第一時間收到異常后端服務器數(shù)量變化的通知，而不是等到用戶報障。

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

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

2. 必備排查工具介紹

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

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

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

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

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

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

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

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

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

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

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

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

2. 安全組規(guī)則精細核查要點

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

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

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

• 快速驗證技巧：利用同一VPC內(nèi)另一臺ECS執(zhí)行 telnet <目標ecs內(nèi)網(wǎng)ip> <健康檢查端口>。假如telnet成功，說明鏈路是通的；不通則幾乎可以定位為安全組或系統(tǒng)防火墻問題。切忌從辦公網(wǎng)直接telnet云上ECS，因為公有云邊界策略通常會攔截這類直接探測。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、應用健康狀態(tài)驗證：服務進程與響應

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

1. 服務進程是否運行

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

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

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

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

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

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

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

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

3. 應用響應超時分析

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

排查時仍用curl -w輸出時間消耗明細：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:端口/健康檢查路徑。重點關(guān)注time_starttransfer（首字節(jié)時間），若該值持續(xù)接近或超過健康檢查超時閾值，說明應用處理環(huán)節(jié)存在瓶頸。此時可用strace -p跟蹤Nginx或Java進程的系統(tǒng)調(diào)用，看是否卡在epoll_wait或futex，也可結(jié)合應用自身的訪問日志和APM工具，定位具體慢在哪一個下游依賴上。

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

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

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

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

健康檢查參數(shù)沒有標準答案，但有一條鐵律：必須比應用真實的啟動與優(yōu)雅停機時間長，同時又能真實反映服務就緒狀態(tài)。

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

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

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

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

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

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

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

3. 定期巡檢不是“有空才做”，而是寫進運維日歷的強制動作

依賴告警是被動響應，依賴巡檢才是主動預防。建議把以下動作固化成周級巡檢清單：

第一，遍歷所有 SLB 監(jiān)聽的后端服務器健康狀態(tài)，拉出最近 7 天內(nèi)異常時長超過 60 秒的節(jié)點，逐一確認異常原因是否已閉環(huán)——大量的偶發(fā)異常會因為“自動恢復”而被遺忘，但下一次可能就是持續(xù)性故障。

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

第三，做一次健康檢查端口的“盲測”：從 SLB 的視角用 telnet 或 curl 驗證所有后端端口，確認沒有因證書過期、DNS 解析變更、應用監(jiān)聽地址綁定為 127.0.0.1 導致的本地可用但遠端不可達。

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