UniFi Dream Router 的安全連線、檢查與設定變更流程

為什麼需要一套固定流程

UniFi Dream Router 是家中網路的核心：網際網路、Wi-Fi、DHCP、DNS、裝置辨識與部分智慧家庭通訊，都會經過它。它一旦設定錯誤，影響的不只是單一裝置，而可能是整個家庭網路。

因此維護 UDR 的重點不是「能不能登入」，而是每次操作都要做到：

先知道要解決什麼問題。
優先使用只讀檢查。
變更前保留原始值。
一次只改一件事。
改完立即讀回並驗證。
預先準備清楚的回復方式。

連線方式如何分工

UniFi Web UI：日常設定的第一選擇

例行維護優先使用 UniFi Web UI，因為畫面會顯示設定關係、欄位限制與目前狀態，也比較不容易因版本差異執行錯誤指令。

適合處理：

查看用戶端是否在線、連到哪個 AP，以及訊號品質。
設定 DHCP 保留位址、裝置名稱與網路分組。
調整 Wi-Fi、DNS、DHCP、防火牆與流量辨識功能。
管理 UniFi 應用程式與系統更新。
只在維護期間暫時開啟 SSH。

Web UI 也是最容易留下「變更前／變更後」截圖的地方，適合當作回復依據。

SSH：診斷與進階維護

SSH 適合 Web UI 看不到的底層狀態，例如記憶體、儲存空間、失敗的系統服務與裝置摘要。

先在受信任的區域網路內暫時開啟 SSH，再連線：

ssh root@<UDR-LAN-IP>

密碼應保存在 macOS Keychain 或可信任的密碼管理器，不寫進 Markdown、Git、Shell 歷史、AI 記憶或部署腳本。維護完成後，應關閉 SSH；若環境允許，則改用 key-only 驗證。

建議的只讀檢查

登入後先建立基準，不急著變更設定：

ubnt-device-info summary
free -m
df -h
systemctl --failed --no-pager

這四項分別回答：

目前裝置、版本與基本系統資訊是否正確。
記憶體與 swap 是否長期吃緊。
儲存空間是否接近滿載。
是否有已知失敗的系統服務。

還要搭配 UniFi Web UI 檢查：

WAN 是否穩定取得連線。
DHCP 與 DNS 是否正常回應。
主要 Wi-Fi 與 AP 是否在線。
重要裝置是否能正常取得位址。
Home Assistant、Matter／Thread 與其他 Home Lab 服務是否仍可通訊。

單一瞬間的 CPU 或記憶體尖峰不等於故障。應該間隔一段時間再次觀察，並對照實際連線品質與服務狀態。

設定變更的安全順序

1. 先定義目的

每次變更前先用一句話寫出目的，例如：

停用沒有使用的應用程式，降低常駐記憶體與 swap 壓力。
關閉不需要的深度封包辨識，減少閘道器負載。
修正 DHCP 保留位址，避免 Home Lab 服務位址漂移。
確認系統更新後的 IPv6 與 Matter／Thread 通訊路徑。
排查手機在家判斷為何沒有跟著 Wi-Fi 連線狀態更新。

如果無法說清楚目的，就不應該先改設定。

2. 保存變更前狀態

依變更範圍選擇至少一種方式：

匯出 UniFi 設定備份。
擷取 Web UI 原始值與畫面。
用只讀指令保存相關設定輸出。
記錄應用程式是否已安裝、目前版本與運作狀態。

備份必須包含「如何還原」，而不只是留下一份不知道怎麼使用的檔案。

3. 優先走支援的設定入口

建議優先順序：

UniFi Web UI。
UniFi OS 提供的應用程式管理工具。
經確認適用於目前版本的 CLI。
直接修改內部資料庫只作最後手段。

內部資料庫結構可能隨 UniFi Network 版本改變。若不得不使用，必須先備份單一設定記錄、確認欄位名稱、只修改必要欄位，再立即讀回比對。

4. 一次只改一項

不要同時移除應用程式、調整 DPI、修改 DHCP 和重新啟動服務。一次只改一項，才能知道改善或故障究竟由哪個動作造成。

5. 立即驗證

變更後至少完成三層驗證：

設定層：新值是否真的寫入
系統層：服務、記憶體、儲存與錯誤是否正常
使用層：上網、Wi-Fi、DNS、Home Assistant 與重要裝置是否可用

「指令成功」只代表指令結束，不代表網路功能一定正常。

6. 準備回復

回復方式可能是：

在 Web UI 把欄位改回原始值。
重新安裝先前移除的 UniFi 應用程式。
匯入變更前備份。
還原單一設定記錄。

若回復會中斷全家網路，應安排維護時段，不在家人正在使用網路時測試。

常見維護目的與判斷方式

降低系統負載

先確認壓力是持續存在，而不是短暫尖峰。檢查記憶體、swap、儲存與應用程式狀態後，再考慮移除未使用的 UniFi 應用程式，或關閉實際沒有使用的分析功能。

排查裝置在家判斷

手機可能使用私有 Wi-Fi 位址，因此應以目前固定的私有 MAC 辨識，不能把可能變動的 DHCP 位址當成永久身分。確認順序是：

手機已連上正確的 Wi-Fi。
UniFi 用戶端清單能看到該裝置。
MAC 與預期識別資料一致。
Home Assistant 的 UniFi 整合已允許並建立對應 tracker。
tracker 再綁定到正確的 person。

更新後智慧家庭通訊異常

若 UDR 更新後 Matter 或 Thread 裝置停止更新，不應立刻重置所有裝置。先檢查：

UDR 的 IPv6 網路與路由是否改變。
Home Assistant 與 Matter Server 是否仍有訂閱更新。
問題是單一裝置，還是整個 Thread 網段。
重新啟動前是否已有可回復的設定與狀態紀錄。

先定位路徑，再決定是否需要重新連線、重新啟動服務或讓單一裝置重新上電。

維護完成檢查表

變更目的已寫清楚。
變更前狀態與回復方式已保存。
使用 Web UI 或目前版本支援的工具。
一次只修改一項設定。
已讀回設定確認真正生效。
WAN、Wi-Fi、DHCP、DNS 與重要服務已驗證。
沒有把密碼、Token、MAC 或內部位址寫進紀錄。
SSH 已關閉，或確認只允許金鑰驗證。

最後留下的原則

UDR 是家庭網路的控制面，不適合用「試看看」的方式維護。最可靠的作法是把每次操作固定成同一條鏈：

目的 → 只讀觀察 → 備份 → 最小變更 → 讀回 → 功能驗證 → 回復或收尾

真正重要的不是記住最多指令，而是確保每次變更都有理由、有證據，也有回去的路。