北京
每一臺 Mac，其實(shí)都有一個(gè)“隱藏的過期時(shí)間”。
當(dāng)系統(tǒng)連續(xù)運(yùn)行 49 天 17 小時(shí) 2 分 47 秒 后，Apple XNU kernel 中一個(gè) 32 位無符號整數(shù)溢出會導(dǎo)致內(nèi)部的 TCP 時(shí)間戳?xí)r鐘被凍結(jié)。一旦這個(gè)時(shí)鐘停止，處于 TIME_WAIT 狀態(tài)的連接將永遠(yuǎn)不會過期，臨時(shí)端口會被慢慢耗盡，最終系統(tǒng)將無法再建立任何新的 TCP 連接。此時(shí)，ICMP（例如 ping）仍然可以正常工作，但除此之外，一切網(wǎng)絡(luò)通信都會“失效”。大多數(shù)人唯一知道的解決辦法，就是重啟機(jī)器。
那么這其中究竟發(fā)生了什么？
近日，AI Agent 公司 Photon 在監(jiān)控 iMessage 服務(wù)的機(jī)器集群時(shí)發(fā)現(xiàn)這個(gè)問題。隨后，其在兩臺機(jī)器上現(xiàn)場復(fù)現(xiàn)了這個(gè) bug，并最終將根因追溯到 XNU 內(nèi)核源碼中的一處比較邏輯，也為我們解釋了 Bug 的來龍去脈。
來源：https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking
作者 | photon 責(zé)編 | 蘇宓
出品 | CSDN（ID：CSDNnews）
背景：你需要了解的幾個(gè)概念
在深入這個(gè) bug 之前，先簡單了解幾個(gè)關(guān)鍵概念。
什么是 TIME_WAIT？
當(dāng)一個(gè) TCP 連接關(guān)閉時(shí)，它并不會立刻消失。
發(fā)起關(guān)閉的一方會進(jìn)入一個(gè)叫做 TIME_WAIT 的狀態(tài)。在這個(gè)狀態(tài)下，連接實(shí)際上已經(jīng)“死亡”——不會再有數(shù)據(jù)傳輸——但操作系統(tǒng)仍然會把它保留一段時(shí)間。
為什么要這么做？主要有兩個(gè)原因：
1. 處理延遲到達(dá)的數(shù)據(jù)包?；ヂ?lián)網(wǎng)并不保證數(shù)據(jù)包按順序到達(dá)。某個(gè)舊連接中的數(shù)據(jù)包，可能仍在網(wǎng)絡(luò)中輾轉(zhuǎn)。如果操作系統(tǒng)立刻復(fù)用同一個(gè)源端口和目標(biāo)地址來建立新連接，這些“遲到”的數(shù)據(jù)包就可能被誤認(rèn)為屬于新連接，從而導(dǎo)致數(shù)據(jù)混亂。
2. 確保連接可靠關(guān)閉。TCP 的四次揮手以主動關(guān)閉方發(fā)送的最后一個(gè) ACK 結(jié)束。如果這個(gè) ACK 丟失，對端會重新發(fā)送 FIN 包。TIME_WAIT 的存在，就是為了讓系統(tǒng)在這段時(shí)間內(nèi)還能正確處理這種重傳。
TIME_WAIT 的持續(xù)時(shí)間被定義為 2 × MSL（最大報(bào)文生存時(shí)間）。當(dāng)這個(gè)時(shí)間過去之后，操作系統(tǒng)才會真正釋放該連接占用的資源——包括它所使用的臨時(shí)端口。
什么是 MSL？
MSL（Maximum Segment Lifetime，最大報(bào)文生存時(shí)間）指的是一個(gè) TCP 報(bào)文在網(wǎng)絡(luò)中被丟棄前，理論上能夠存活的最長時(shí)間。
1981 年發(fā)布的 TCP 原始規(guī)范 RFC 793 將 MSL 設(shè)定為 2 分鐘，因此 TIME_WAIT 的時(shí)長就是 4 分鐘。
但在實(shí)際系統(tǒng)中，現(xiàn)代操作系統(tǒng)通常使用更短的時(shí)間：
Linux：MSL 為 30 秒，對應(yīng) TIME_WAIT 為 60 秒
macOS / XNU kernel：MSL 為 15 秒，對應(yīng) TIME_WAIT 為 30 秒
Windows：默認(rèn) MSL 為 120 秒，對應(yīng) TIME_WAIT 為 240 秒
在 macOS 上，一個(gè)關(guān)閉的 TCP 連接只會在 TIME_WAIT 狀態(tài)停留 30 秒就會被清理掉。這個(gè)速度其實(shí)很快——前提是清理機(jī)制本身沒有出問題。
什么是 32 位無符號整數(shù)回繞（wraparound）？
在 C 語言中，一個(gè) uint32_t 能表示的范圍是 0 到 4,294,967,295（232 ? 1）。當(dāng)你嘗試存儲一個(gè)超過這個(gè)最大值的數(shù)字時(shí)，它不會報(bào)錯(cuò)，而是“回繞”到 0，就像里程表從 999,999 翻回 000,000 一樣。
這并不是崩潰，也不是異常，而是 C 語言對無符號整數(shù)的定義行為。真正的風(fēng)險(xiǎn)在于：如果代碼默認(rèn)這個(gè)計(jì)數(shù)器只會遞增，而沒有考慮回繞的情況，就可能埋下隱患。
這類問題其實(shí)并不罕見，比如：
Windows 95 / Windows 98 的 49.7 天崩潰問題：內(nèi)核的 32 位毫秒計(jì)數(shù)器溢出后，相關(guān)組件沒有正確處理回繞，導(dǎo)致系統(tǒng)卡死。
2038 年問題：使用 32 位有符號整數(shù)記錄時(shí)間（自 1970 年起的秒數(shù)）的 Unix 系統(tǒng)，會在 2038 年 1 月 19 日發(fā)生溢出。
GPS 周數(shù)翻轉(zhuǎn)：GPS 使用 10 位周計(jì)數(shù)器，每 1024 周（約 19.7 年）回繞一次，可能導(dǎo)致部分設(shè)備顯示錯(cuò)誤日期。
吃豆人 256 關(guān)的“死機(jī)畫面”：8 位整數(shù)溢出使游戲在 255 關(guān)之后變得無法繼續(xù)。
我們在 macOS 中發(fā)現(xiàn)的這個(gè) bug，正屬于同一類問題。XNU 內(nèi)核使用一個(gè) uint32_t 來記錄 TCP 時(shí)間戳，單位是毫秒，自系統(tǒng)啟動開始計(jì)數(shù)。232 毫秒正好是 49 天 17 小時(shí) 2 分 47.296 秒。一旦超過這個(gè)時(shí)間，計(jì)數(shù)器就會回繞歸零。
接下來會發(fā)生什么，正是這篇文章要講的重點(diǎn)。
發(fā)現(xiàn)過程：一個(gè)我們從未察覺的“計(jì)時(shí)炸彈”
在 Photon，我們運(yùn)行著一批 Mac 機(jī)器，用來監(jiān)控 iMessage 服務(wù)的健康狀況。這些機(jī)器上跑著多個(gè) iMessage 服務(wù)實(shí)例，并由一個(gè)中央控制器持續(xù)發(fā)送 ping/pong 消息來測量往返延遲。這些機(jī)器是 24/7 持續(xù)運(yùn)行的，只有在絕對必要時(shí)才會重啟。
2026 年 3 月 30 日——也就是距離上一次統(tǒng)一重啟正好 49.7 天——集群中的幾臺機(jī)器，開始悄無聲息地?zé)o法建立新的 TCP 連接。
奇怪的是，ping 依然正常，已有連接也沒有斷開，但凡是需要創(chuàng)建新 TCP socket 的操作，全部失敗。
這個(gè)現(xiàn)象非常典型：XNU kernel 的 TCP 時(shí)間戳計(jì)數(shù)器發(fā)生了回繞，而內(nèi)部的單調(diào)性保護(hù)阻止它在溢出后繼續(xù)更新。結(jié)果就是——TCP 內(nèi)部時(shí)鐘被凍結(jié)了。
接下來就是連鎖反應(yīng)：TIME_WAIT 連接不再過期，臨時(shí)端口不斷堆積，卻無法被回收。
最終，系統(tǒng)徹底無法再建立新的連接。唯一的恢復(fù)方式就是重啟——但這不過是重新開始下一輪 49.7 天的倒計(jì)時(shí)。
在重啟這些出問題的機(jī)器以恢復(fù)服務(wù)后，我們檢查了整個(gè)集群，發(fā)現(xiàn)還有幾臺機(jī)器也接近同樣的臨界點(diǎn)——它們將在 4 月 1 日達(dá)到 49.7 天的運(yùn)行時(shí)間。
于是我們決定做一個(gè)“現(xiàn)場實(shí)驗(yàn)”。
兩臺機(jī)器（Machine A 和 Machine B）的啟動時(shí)間如下：
Machine B: { sec = 1770762608 } Tue Feb 10 14:30:08 2026兩臺機(jī)器當(dāng)時(shí)都已經(jīng)運(yùn)行了 49 天 16 小時(shí)。精確的溢出時(shí)間如下：
Machine B：2026-04-01 08:32:55 PDT（剩余約 36 分鐘）也就是說，我們大約還有半小時(shí)來準(zhǔn)備實(shí)驗(yàn)——時(shí)間剛剛好。
實(shí)驗(yàn)設(shè)計(jì)：跨越溢出窗口批量制造 TCP 連接
我們的假設(shè)很直接：如果這個(gè) 49.7 天的溢出真的會破壞 TIME_WAIT 的回收機(jī)制，那么在溢出前后制造一批短連接，應(yīng)該能看到明顯的行為差異：
溢出前：TIME_WAIT 連接會在約 30 秒后正常過期
溢出后：TIME_WAIT 連接將“永久滯留”
為此，我們寫了一個(gè)測試腳本，分為三個(gè)階段：
首先是監(jiān)控階段（溢出前 35 分鐘到溢出前 5 分鐘）：每 10 秒記錄一次 TIME_WAIT 連接數(shù)量，不主動創(chuàng)建連接。
然后是沖擊階段（溢出前 5 分鐘到溢出后 5 分鐘）：每 2 秒發(fā)起約 15 個(gè)短生命周期 TCP 連接，請求公共端點(diǎn)（例如 8.8.8.8:443、1.1.1.1:443 等），完成 TLS 握手后立即關(guān)閉。
最后是觀察階段：停止創(chuàng)建新連接，繼續(xù)監(jiān)控 TIME_WAIT 的數(shù)量變化。
這個(gè)腳本在 07:58 被部署到兩臺機(jī)器上，并同時(shí)啟動。
實(shí)驗(yàn)結(jié)果
溢出前：TIME_WAIT 正?；厥?/strong>
在監(jiān)控階段，兩臺機(jī)器的 TIME_WAIT 表現(xiàn)完全健康：
[08:27:28] PHASE=wait | remain=306s | TIME_WAIT=0 | ESTABLISHED=41系統(tǒng)自身的后臺連接會產(chǎn)生少量 TIME_WAIT（0–13），并且會在幾秒內(nèi)過期。這是完全正常的行為。
沖擊階段：溢出前的動態(tài)平衡
08:27:38，腳本開始創(chuàng)建連接。不到 30 秒，TIME_WAIT 從 0 上升到約 200，并隨后進(jìn)入平臺期：
[08:31:37] PHASE=blast | remain=57s | TIME_WAIT=192腳本每 2 秒創(chuàng)建約 15 個(gè)連接（約每分鐘 450 個(gè)），而每個(gè) TIME_WAIT 只會存活 30 秒就被回收。大約 30 秒后，系統(tǒng)進(jìn)入動態(tài)平衡：TIME_WAIT 穩(wěn)定在約 200 左右（理論值為 7.5 次/秒 × 30 秒 = 225；略低是因?yàn)椴糠诌B接失?。?。創(chuàng)建與回收保持完美平衡，這就是溢出前的健康狀態(tài)。
溢出瞬間
[08:32:39] PHASE=blast | remain=-5s | TIME_WAIT=428腳本使用墻上時(shí)間（date +%s）來估算溢出倒計(jì)時(shí)，而內(nèi)核的 microuptime() 是單調(diào)時(shí)鐘。經(jīng)過 49.7 天，兩者會產(chǎn)生幾十秒的偏差。從完整日志來看，TIME_WAIT 實(shí)際開始單調(diào)上升是在 remain≈28 秒（約 08:32:06）時(shí)——這才是回收機(jī)制真正停止的時(shí)間點(diǎn)。
連接依然以相同速率被創(chuàng)建，但沒有任何一個(gè)被回收。
溢出后：TIME_WAIT 只增不減
Machine A 的腳本在溢出后約 50 秒停止，Machine B 則繼續(xù)運(yùn)行了 5 分鐘。兩臺機(jī)器的監(jiān)控都持續(xù)到手動終止。
Machine B 的關(guān)鍵數(shù)據(jù)（腳本在 08:37:55 停止創(chuàng)建連接）：
這就是決定性證據(jù)。在 macOS 中，TIME_WAIT 超時(shí)時(shí)間是 2 × MSL = 30 秒。腳本停止 84 秒后，全部 2,828 個(gè) TIME_WAIT 連接本應(yīng)已經(jīng)歸零。但現(xiàn)實(shí)是，沒有任何一個(gè)被回收——數(shù)量甚至還在增加，因?yàn)橄到y(tǒng)自身的正常連接也開始不斷堆積。
Machine A（腳本已停止，08:50 手動檢查）：
持續(xù)單調(diào)增長，沒有任何恢復(fù)跡象。
對比：溢出前 vs 溢出后
觀測數(shù)據(jù)：399, 412, 428, 443, 458, 473, 487, 502 ……（單調(diào)增長）
根本原因：XNU 內(nèi)核中 tcp_now 的 32 位溢出
接下來解釋為什么會發(fā)生這個(gè)問題，逐行分析 Apple 內(nèi)核源碼。
漏洞分類
這是 TCP 子系統(tǒng)中的 32 位無符號整數(shù)計(jì)時(shí)器溢出錯(cuò)誤，具體來說是 TCP 時(shí)間戳計(jì)數(shù)器的溢出。受影響的計(jì)數(shù)器 tcp_now 是內(nèi)核的內(nèi)部 TCP 時(shí)鐘。一旦它停止計(jì)數(shù)，TCP 棧中所有依賴它的定時(shí)器都會失效。
tcp_now：注定會溢出的計(jì)數(shù)器
在 XNU 內(nèi)核（Apple 開源項(xiàng)目 apple-oss-distributions/xnu）中，tcp_now 定義在 bsd/netinet/tcp_var.h：
#define TCP_RETRANSHZ 1000 /* TCP 時(shí)間戳的精度，1 毫秒 */這是一個(gè) 32 位無符號整數(shù)，以毫秒為單位遞增，跟蹤自開機(jī)以來的時(shí)間。每當(dāng) TCP 子系統(tǒng)需要獲取當(dāng)前時(shí)間戳?xí)r，會調(diào)用 calculate_tcp_clock()（基于 XNU 內(nèi)核源碼分析）：
}關(guān)鍵在于這一行：(uint32_t)now.tv_sec * 1000。當(dāng)系統(tǒng)運(yùn)行了 4,294,967 秒（約 49.7 天）后，這個(gè)乘法結(jié)果超過了 uint32_t 的最大值 4,294,967,295。強(qiáng)制轉(zhuǎn)換為 uint32_t 會導(dǎo)致無符號整數(shù)回繞——數(shù)值從接近最大值直接跳回接近零。
為什么 tcp_now 在溢出后會凍結(jié)
漏洞出現(xiàn)在這一段保護(hù)邏輯中：
}設(shè)計(jì)意圖很簡單：“tcp_now 必須只向前移動。”在正常情況下，這段邏輯工作正常。但在溢出瞬間：
比較：4,294,960,000 < 5,000？ → false！舊值 tmp（接近最大）大于 new 值 current_tcp_now（回繞到接近零），cmpxchg 永遠(yuǎn)不會執(zhí)行。結(jié)果，tcp_now 鎖定在溢出前的值，再也不會更新。
內(nèi)核的 TCP 時(shí)鐘徹底停止。
TIME_WAIT 過期檢查失效機(jī)制
當(dāng) TCP 連接進(jìn)入 TIME_WAIT 狀態(tài)時(shí)，內(nèi)核會記錄一個(gè)絕對過期時(shí)間。在`bsd/netinet/tcp_timer.c`文件中，`add_to_time_wait_locked()`函數(shù)實(shí)現(xiàn)了該邏輯：
}此處延遲時(shí)長計(jì)算公式為：延遲 = 2 × TCPTV_MSL = 2 × 15000 = 30000毫秒。
內(nèi)核的垃圾回收函數(shù)`tcp_gc()`會周期性掃描 TIME_WAIT 隊(duì)列：
}`TSTMP_GEQ`宏定義在`bsd/netinet/tcp_seq.h`文件中：
#define TSTMP_GEQ(a, b) ((int)((a)-(b)) >= 0)這是一種標(biāo)準(zhǔn)的有符號模運(yùn)算比較方式，專門用于處理序列號回繞問題。正常情況下（`tcp_now`持續(xù)遞增），當(dāng)`tcp_now`大于等于過期時(shí)間時(shí)，該宏會返回 true，連接會被內(nèi)核清理。
但當(dāng)`tcp_now`被凍結(jié)時(shí)：
= -30000 >= 0 ? → false!計(jì)算結(jié)果一直是 false，連接永遠(yuǎn)不會被回收。
完整因果鏈
Application-layer timeouts, services become unreachable
連鎖反應(yīng)：從時(shí)鐘凍結(jié)到 TCP 完全失效
這個(gè)漏洞的致命之處在于靜默失效：不會觸發(fā)內(nèi)核恐慌、無錯(cuò)誤日志、無崩潰報(bào)告。系統(tǒng)表面看起來完全正常，直到 TCP 服務(wù)徹底癱瘓。
故障演進(jìn)過程：
1. 溢出后數(shù)分鐘后：TIME_WAIT 連接停止過期。如果業(yè)務(wù)僅創(chuàng)建少量短連接，數(shù)小時(shí)內(nèi)都無法察覺異常；
2. 溢出后數(shù)小時(shí)：TIME_WAIT 連接堆積至數(shù)千個(gè)，系統(tǒng)臨時(shí)端口（macOS 默認(rèn)范圍為 49152~65535，共 16384 個(gè)）開始耗盡；
3. 端口耗盡：新的出站連接無法綁定本地端口，卡在 SYN_SENT 狀態(tài)并失敗。已建立的長連接（ESTABLISHED）不受影響，因?yàn)橐颜加枚丝冢?/p>
4. 系統(tǒng)負(fù)載飆升：內(nèi)核持續(xù)消耗 CPU 資源掃描龐大且永不縮減的 TIME_WAIT 隊(duì)列，應(yīng)用不斷重試失敗連接，進(jìn)一步加重負(fù)載；
5. TCP 徹底失效：僅 ICMP 協(xié)議（ping 命令）可用，因?yàn)樗灰蕾?TCP 端口和 TCP 定時(shí)器子系統(tǒng)。
唯一恢復(fù)方案：重啟系統(tǒng) → 重置 tcp_now 為 0，重新開始 49.7 天的倒計(jì)時(shí)。
佐證依據(jù)
RFC 7323 與時(shí)間戳回繞
RFC 7323（高性能 TCP 擴(kuò)展）第 5.4 節(jié)（時(shí)間戳?xí)r鐘）中提到，以 1 毫秒為精度的 32 位時(shí)間戳，大約在 24.8 天（231 ms）后會發(fā)生符號位回繞。第 5.5 節(jié)（過期時(shí)間戳）要求 PAWS 實(shí)現(xiàn)必須在連接空閑超過 24 天后，將緩存的時(shí)間戳置為無效。
我們觀測到的溢出周期是 49.7 天，也就是完整的無符號數(shù)回繞周期 232 ms，正好是 RFC 中符號位回繞周期的兩倍。RFC 討論的是傳輸過程中對端 TCP 時(shí)間戳選項(xiàng)的回繞，而不是本地內(nèi)核自身的定時(shí)器變量，后者屬于 XNU 實(shí)現(xiàn)上的缺陷。
社區(qū)中一致的故障現(xiàn)象報(bào)告
蘋果社區(qū)論壇和開源項(xiàng)目中，有多份報(bào)告描述的癥狀與該漏洞完全吻合：
蘋果社區(qū)帖子 ：macOS Catalina 下“無法建立新的 TCP 連接”。新連接進(jìn)入 SYN_SENT 后立即關(guān)閉，已有連接不受影響，只有重啟才能恢復(fù)。
蘋果社區(qū)帖子 ：“Mac Pro TCP/IP 停止工作”。TCP 完全失效，但 ping（ICMP）仍然正常。
Podman 問題 ：在 macOS 12 上“podman 虛擬機(jī)在運(yùn)行一段時(shí)間后網(wǎng)絡(luò)連接卡住”。運(yùn)行數(shù)周后，運(yùn)行在 macOS 上的虛擬機(jī)出現(xiàn) TCP 出站失敗，但 ICMP 仍然可用。
這些報(bào)告的共同特征：TCP 失效但 ICMP 正常，只有重啟才能解決，并且發(fā)生在連續(xù)運(yùn)行數(shù)周之后。這與 tcp_now 溢出的預(yù)測癥狀完全一致。ICMP 不使用 TCP 定時(shí)器子系統(tǒng)，因此不受影響。
影響范圍：哪些設(shè)備會受影響？
任何同時(shí)滿足以下兩個(gè)條件的 macOS 系統(tǒng)：
連續(xù)運(yùn)行時(shí)間超過 49 天 17 小時(shí)且未重啟
存在任何 TCP 網(wǎng)絡(luò)活動（幾乎所有聯(lián)網(wǎng)的 Mac）
大多數(shù)普通 Mac 會因?yàn)橄到y(tǒng)更新在 49 天內(nèi)重啟，因此普通用戶很少觸發(fā)此問題。但以下場景屬于高風(fēng)險(xiǎn)：
長期運(yùn)行的服務(wù)器集群（例如我們的 iMessage 監(jiān)控系統(tǒng)）
macOS CI/CD 構(gòu)建服務(wù)器（Jenkins、GitHub Actions 自托管運(yùn)行器）
Mac Pro 工作站（長期渲染、編譯或仿真任務(wù)）
托管機(jī)房中的 Mac（遠(yuǎn)程管理，很少重啟）
用作構(gòu)建集群或測試環(huán)境的 Mac mini 集群
復(fù)現(xiàn) Bug 方法
想在你自己的 macOS 設(shè)備上驗(yàn)證這個(gè)漏洞？只需四步。
步驟 1：計(jì)算溢出時(shí)間
echo "Time until overflow: $((remain/3600))h $((remain%3600/60))m $((remain%60))s"步驟 2：在溢出前后監(jiān)控 TIME_WAIT 數(shù)量
done步驟 3：在溢出窗口內(nèi)生成連接
done步驟 4：觀察現(xiàn)象
停止生成連接，等待 2 分鐘。如果 TIME_WAIT 數(shù)量沒有下降，說明漏洞已復(fù)現(xiàn)。
9.5 小時(shí)后：親眼見證系統(tǒng)癱瘓
溢出后我們沒有重啟，而是讓兩臺機(jī)器繼續(xù)運(yùn)行，觀察漏洞自然惡化的全過程。
溢出后 9.5 小時(shí)的系統(tǒng)狀態(tài)（PDT 18:02）
Load: 49.74TIME_WAIT 累積趨勢
沒有任何一個(gè) TIME_WAIT 連接被回收。數(shù)量只增不減。
SYN_SENT 堆積：新建連接大量失敗
溢出 9.5 小時(shí)后，兩臺機(jī)器都積累了 3000 以上的 SYN_SENT 連接，這是 TCP 端口耗盡的典型表現(xiàn)：
出站連接卡在三次握手的第一步，無法申請到端口
臨時(shí)端口被永不釋放的 TIME_WAIT 占用
只剩下 37–38 個(gè) ESTABLISHED 連接，已有的長連接仍然正常，但新建連接幾乎無法建立
機(jī)器 B 的系統(tǒng)負(fù)載飆升到 49.74，因?yàn)閮?nèi)核在不斷掃描不斷膨脹的 TIME_WAIT 隊(duì)列，消耗大量 CPU
這與我們預(yù)測的惡化過程完全一致：
→ Only recovery: reboot
結(jié)論
一個(gè) 32 位整數(shù)。一段看似無害的 if (tmp < current_tcp_now) 保護(hù)機(jī)制。49.7 天的等待。就足以埋下一顆定時(shí)炸彈。
這類漏洞非常隱蔽，因?yàn)樗氵^了所有防御環(huán)節(jié)。它不會在開發(fā)測試中被發(fā)現(xiàn)，誰會做連續(xù) 50 天的測試？它不會在代碼審查中被標(biāo)記，邏輯看起來完全合理。它甚至可能在生產(chǎn)環(huán)境中被誤診為網(wǎng)絡(luò)問題或硬件故障。只有當(dāng)你剛好盯著一臺運(yùn)行了 49 天的機(jī)器，并且剛好知道 232 毫秒等于 49.7 天時(shí)，整個(gè)謎題才會被解開。
我們在多臺服務(wù)器上復(fù)現(xiàn)了該問題，證據(jù)確鑿：溢出前，TIME_WAIT 正常過期（0–13 個(gè)）；溢出后，TIME_WAIT 永遠(yuǎn)不回收（累積到數(shù)千個(gè)）。tcp_now 被凍結(jié)，內(nèi)核的 TCP 時(shí)鐘停止。其他一切看起來都正常，直到端口耗盡。
如果你管理長期運(yùn)行的 macOS 設(shè)備，請記住這個(gè)時(shí)間：
49 天 17 小時(shí) 2 分鐘 47 秒。
我們正在開發(fā)比重啟更好的修復(fù)方案，一個(gè)不需要完整重啟、專門解決 tcp_now 凍結(jié)的臨時(shí)修復(fù)方案。在此之前，請?jiān)跁r(shí)鐘溢出前安排重啟。
【活動分享】"48 小時(shí)，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點(diǎn)智能研究院聯(lián)合舉辦的「全球機(jī)器學(xué)習(xí)技術(shù)大會」正式升級為「奇點(diǎn)智能技術(shù)大會」。2026 奇點(diǎn)智能技術(shù)大會將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實(shí)踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團(tuán)等頭部企業(yè)的 50+ 位技術(shù)決策者分享實(shí)戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風(fēng)險(xiǎn)、降低試錯(cuò)成本、獲取可復(fù)用的工程方法論，真正實(shí)現(xiàn) AI 技術(shù)的規(guī)?；涞嘏c商業(yè)價(jià)值轉(zhuǎn)化。這不僅是一場技術(shù)的盛宴，更是決策者把握 2026 AI 拐點(diǎn)的戰(zhàn)略機(jī)會。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
夢回千年aa
