診斷週期性 Wi-Fi 延遲尖刺 (latency spike)¶

症狀：某台裝置（常見是手機/平板打遊戲）平均 ping 還好——例如 20–30 ms——但會週期性飆到數百 ms一兩秒,然後恢復。頻寬沒問題,壞就壞在這種一陣一陣的延遲毀掉即時應用。

本頁是一道診斷階梯 (diagnostic ladder),依「每一階排除問題的成本由低到高」排序,逐步釘出尖刺到底來自哪裡。用到的工具： ping-monitor、tv wifi-scan, 以及（Ruijie/Reyee 路由器專用）reyee。

Terminology rule (zh-TW pages)

技術名詞首次出現以「中文 (English original)」格式呈現。不自創翻譯——若無公認譯名直接保留英文。代碼、API 名、CLI flag、套件名、檔名一律不翻。

心智模型 (mental model)¶

「平穩低延遲 + 週期性大尖刺」這種樣態,幾乎不是 ISP 或遊戲伺服器——那些會表現為整段基線偏高、或丟包,而不是乾淨的 1.5 ms 每隔幾秒跳到 300 ms。乾淨鏈路上的陣發尖刺,代表本地有東西週期性搶走空中時間 (airtime),或讓無線電 (radio) 短暫無法服務：

同頻/鄰頻干擾 (co-channel / adjacent interference) — 另一台 AP 或裝置和你共用頻道。Wi-Fi 是半雙工 (half-duplex),鄰居在發時你就得等。
客戶端背景掃描 (client-side scanning) — 筆電/手機為了漫遊 (roaming),短暫離開頻道去掃其他 AP。只影響那一台裝置。
AP 端背景掃描 / RRM — 存取點 (access point) 週期性離開頻道做環境勘測（防蹭網 /rogue 偵測、自動選頻、雲端「Wi-Fi 優化」）。會打到該無線電上的每一台 client, 而且跟你選哪個頻道無關。
無線中繼 / mesh 回程 (wireless repeater / backhaul) — 中繼器若用同頻段連主路由,會把空中時間砍半並週期性卡住。
緩衝膨脹 (bufferbloat) — 只在有負載時發生;不是閒置鏈路尖刺的成因。

第 1 階 — ping 你自己的閘道（到底是不是本地?)¶

ping-monitor --gateway 10 1     # 對第一跳,>10ms 就標記

閘道是第一跳 (first hop)——你自己的路由器。如果它就會噴,問題出在你和路由器之間（或路由器本身）,跟外網路徑無關。這一個測試就能一次排除 ISP、GFW、路由、遊戲伺服器。

閘道乾淨、只有外網目標噴 → 往上游查（本頁範圍外）。
閘道就會噴 → 是本地問題。 繼續。

第 2 階 — 是無線端,還是路由器?¶

把閘道測試改用有線重做（插網線、關 Wi-Fi）：

ping-monitor --gateway 10 1

有線乾淨、Wi-Fi 才噴 → 是無線電端（干擾、掃描、或中繼器）。這是常見情形。
有線也噴 → 是路由器本身（CPU、韌體 (firmware)、某個狂發封包的 client）。去看路由器自己的診斷和 client 列表。

第 3 階 — 你的訊號其實夠好嗎?(排除距離)¶

訊號弱會造成重傳 (retry),看起來就像尖刺。檢查 RSSI / 雜訊 (noise) / 訊噪比 (SNR)：

# macOS
system_profiler SPAirPortDataType -json | python3 -m json.tool | less
# Linux
iw dev wlan0 link        # 或: nmcli -f IN-USE,SSID,SIGNAL,CHAN,FREQ dev wifi

經驗法則（5 GHz）：RSSI ≥ -60 dBm 且 SNR ≥ 25 dB 就夠用。 如果你是 -30 dBm、 SNR 60 卻還在噴,訊號強度就不是主因——別再往這方向追。

第 4 階 — 勘測頻道鄰居¶

tv wifi-scan          # 模糊搜尋附近 AP;preview 顯示每頻道佔用 + 非-DFS 建議
wifiscan              # alias:先掃一次

找有沒有另一台強 AP 跟你同頻道（co-channel）,以及你是不是落在 DFS 頻道（5 GHz 52–64 / 100–144——這些要做雷達偵測,本身會插入暫停）。

若有同頻競爭,換到乾淨的非-DFS 頻道（36/40/44/48 或 149/153/157/161/165）。 Ruijie/Reyee 路由器：

reyee set-channel --band 5g --channel 36          # 先 dry-run
reyee set-channel --band 5g --channel 36 --yes    # 套用（會短暫斷 Wi-Fi）

改完等它穩定再重測（見下方 pitfall）。如果換到乾淨的非-DFS 頻道沒有改善, 那成因就跟頻道無關 → 是掃描（第 5 階）。

第 5 階 — 跟頻道無關的尖刺 = 掃描¶

如果你走到這裡——閘道會噴、有線乾淨、訊號極佳、頻道乾淨且換了也沒用,而且多台裝置都噴（不只一台）——成因就是 AP 週期性離開頻道掃描,或無線中繼器在搶空中時間。

區分兩者：

把中繼器/額外 mesh 節點斷電或移除,等穩定後對主 AP 重測。單一 AP 還噴 → 是主 AP 自己在掃描。
無線中繼器和主無線電共用頻道,本身就是週期性的空中時間竊賊;若確認是它,把它改成 有線回程 (wired backhaul)（或拿掉）就是解法。

消費級雲端管理 (cloud-managed) 路由器（Ruijie/Reyee「易聯」/ Ruijie Cloud、部分 TP-Link/ASUS「AiMesh」RRM 等）的 AP 端背景掃描,UI 上常常沒有乾淨的關閉開關。真正有用的拉桿：

更新韌體 — 背景掃描造成的延遲是已知、且常被修的一類 bug。
把多餘的 mesh 節點從設定中移除（不只是斷電）,讓控制器別再週期性找它。
退出雲端管理 / 改成本地 (local) 或 AP 模式,停掉雲端的週期性優化掃描。
最後手段:接受它,或換成掃描可關的 AP（例如 OpenWrt,可直接停掉背景掃描）。

Pitfall:別在「重配風暴」當下量測¶

幾乎每台 AP 在改頻道 / mesh / 頻段時都會觸發 1–2 分鐘的重新配置（Reyee 自己都會印「配置中可能会出现卡顿，属于正常现象」）。如果你一改完馬上測,量到的是風暴而不是穩定狀態——會錯誤地下結論說這個改動「更糟」。

任何改動後一律等 ~10 分鐘、待在同一個位置,再跑長測（ping-monitor --gateway 10 300 跑 5 分鐘）才下結論。測到一半在房間之間走動也會換 AP/換訊號——請定點。

案例研究（本 repo 的家用網路）¶

產出本頁的真實一次排查（已去識別化）：

症狀: iPad 打遊戲,基線 ~25 ms,週期性飆到 ~500 ms。
第 1 階: 閘道 ping 飆到 40–97 ms（p95 67 ms）——本地。
第 3 階: Mac 走 5 GHz,RSSI -27 dBm、SNR 67、866 Mbps——訊號完美,不是距離。
第 4 階: 有鄰居 AP 跟你同頻道（ch 52,還是 DFS）。把主路由 52 → 36,沒改善。發現是兩台 Reyee AP（主 + 一台無線中繼）;子 AP 還在 ch 52,改成 149,仍沒改善——而且改完當下更糟,因為量在重配風暴裡。
第 2 階: 有線閘道 ping = 0 尖刺,p99 1.4 ms。路由器/LAN/CPU 都沒問題, 純無線電端。
第 5 階: 把中繼器斷電、等穩定,對單一 AP、訊號完美、乾淨非-DFS 頻道重測 → 還是 p95 282 ms、p99 345 ms、4 分鐘 66 個尖刺。頻道、訊號、同頻、中繼器全部排除。Mac 和 iPad 都噴。
結論: 雲端管理（Ruijie Cloud / 易聯）的主 AP 週期性離開頻道掃描——跟頻道無關、打到所有 client、API/UI 都沒有開關。剩下的拉桿:更新韌體、把 mesh 節點從設定移除、或退出雲端 / 切換工作模式。

重點:換頻道是第 4 階,不是答案。 當尖刺跟頻道無關、又在完美鏈路上打到每一台裝置時,要懷疑 AP 自己的掃描——而且絕不要相信任何「剛改完就測」的單次結果。