OpenWrt 與 UniFi AP 的責任邊界¶

狀態：已發布
領域：網路／OpenWrt／Wi-Fi
理解確認：Kent 已於 2026-08-15 明確確認理解核心概念
內容核准：Kent 已於 2026-08-15 核准本文發布

這篇文章回答什麼問題？

當 OpenWrt 與 UniFi AP 共存時，Router、AP 與 Controller 各自負責什麼？為什麼 Controller 停止後，已完成設定的 AP 通常仍能讓既有 Client 上網？本文從資料平面、控制平面與故障邊界說明這套架構。

適用範圍

本文描述 OpenWrt 作為唯一 Router／Gateway、UniFi AP 作為 Layer-2 無線接入設備、UniFi Network Application 作為 AP 管理平面的常見架構。若使用 UniFi Gateway、Portal、動態認證或其他需要 Controller 持續在線的功能，故障行為可能不同。

先看結論¶

OpenWrt
→ Router data plane
→ WAN、routing、NAT、firewall、DHCP、DNS、VPN

UniFi AP
→ Wireless access data plane
→ 將 Wi-Fi client 橋接到 Ethernet LAN

UniFi Controller
→ AP management／control plane
→ Adoption、設定、provisioning、監控與韌體管理

正常的 Client 封包路徑是：

Wi-Fi client
→ UniFi AP
→ Ethernet LAN
→ OpenWrt
→ Internet

Controller 不應位於一般 Client 的 packet-forwarding path。因此，Controller 停止不等於 Router 或 AP data plane 立即停止。

一、OpenWrt：唯一的 Router／Default Gateway¶

在這種分工下，OpenWrt 負責 Layer-3 網路服務：

WAN 連線，例如 DHCP、Static IP 或 PPPoE。
IP routing 與 default route。
NAT／masquerading。
Stateful firewall。
LAN DHCP。
LAN DNS 入口與上游轉送。
VPN routing 與 firewall policy。
VLAN 之間的 routing 與存取控制。

有線與 Wi-Fi Client 最終都把 OpenWrt 當作 default gateway。

因此，如果 OpenWrt 停止，即使 AP 仍在廣播 SSID，Client 也可能只連上一個缺少 DHCP、DNS 或 Internet gateway 的 Layer-2 網路。

二、UniFi AP：無線 Layer-2 Access Data Plane¶

在單純的 AP 模式中，UniFi AP 的核心工作是：

802.11 Wi-Fi frame
→ AP bridge
→ Ethernet frame
→ LAN

AP 負責：

SSID 與 Wi-Fi security。
Radio、channel、channel width 與 transmit power。
Wi-Fi Client association。
將無線流量橋接到對應 LAN／VLAN。

AP 通常不負責：

WAN 連線或 PPPoE。
Internet default route。
NAT。
LAN DHCP。
Internet-facing firewall。
一般 LAN DNS forwarding。

若部署 VLAN，AP 可以依 SSID 加上 VLAN tag，但跨 VLAN routing 與 firewall policy 仍應由 OpenWrt 負責。

三、UniFi Controller：管理與控制平面¶

UniFi Network Application 負責：

AP adoption。
建立與修改 SSID。
設定 radio、channel 與 transmit power。
將設定 provision 到 AP。
顯示 AP 與 Client 狀態。
收集監控與統計資訊。
韌體與設定備份管理。

完成 provisioning 後，AP 會保存最後一次有效設定。Controller 通常不會逐包轉送一般 Client 流量。

所以 Controller 很重要，但其主要角色是：

管理 AP 如何運作，而不是代替 AP 或 OpenWrt 轉送每一個 Client 封包。

四、Controller 停止時會發生什麼？¶

假設：

AP 已完成 adoption 與 provisioning
AP 本身仍在線
OpenWrt 正常
只有 Controller 停止

基本資料平面通常仍可維持：

AP 繼續廣播已保存的 SSID。
既有安全設定仍由 AP 使用。
Client 仍可 association。
AP 繼續將流量橋接至 LAN。
OpenWrt 繼續提供 DHCP、DNS、NAT、firewall 與 WAN routing。
既有 Client 通常仍可連線與上網。

但會失去或暫停：

Controller 管理介面。
即時監控與完整統計。
新 AP adoption。
修改 SSID、密碼與 radio 設定。
新設定 provisioning。
透過 Controller 執行的韌體管理。
明確依賴 Controller 在線的進階功能。

因此，準確的結論是：

Controller 離線通常不影響已 provision AP 的基本 forwarding，但會失去集中管理、監控、變更與部分進階功能。

五、三種故障的影響不同¶

故障元件	Wi-Fi Radio／SSID	Wi-Fi Bridge	DHCP／DNS	Internet Routing
Controller	通常保留既有設定	通常保留	OpenWrt 繼續提供	OpenWrt 繼續提供
AP	該 AP 的 Wi-Fi 中斷	該 AP 中斷	OpenWrt 本身仍在	有線端與其他 AP 仍可使用
OpenWrt	AP 可能仍廣播	Layer 2 可能仍存在	中斷或不完整	中斷

這張表顯示三個元件不是彼此替代，而是處於不同層次。

六、為什麼 UniFi Network Metadata 仍要對齊？¶

即使 UniFi 不負責 routing，其 Network 設定仍應描述真實 LAN：

Subnet metadata：與 OpenWrt LAN 一致
Gateway metadata：指向 OpenWrt
DHCP：在 UniFi 側關閉
VLAN：與實際 OpenWrt／Switch 設計一致

這不是把網路責任交給 UniFi，而是避免管理資料與真實網路脫節。

如果 metadata 錯誤，可能造成：

Controller 顯示錯誤的 subnet 或 gateway。
未來加入 Switch 或 VLAN 時套用錯誤設定。
SSID 與 VLAN 關聯混亂。
維護者誤以為 UniFi 正在提供 DHCP。
不慎啟用第二個 DHCP server。

需要記住：

Metadata 對齊
≠
功能責任轉移

UniFi 可以知道真實 LAN 的資訊，但 gateway、DHCP、DNS 與 firewall 仍由 OpenWrt 負責。

七、為什麼不能同時開兩個 DHCP Server？¶

如果 OpenWrt 與另一個設備同時在相同 broadcast domain 回覆 DHCP：

Client 可能隨機接受不同 DHCP Offer。
不同 Client 可能拿到不同 gateway 或 DNS。
問題可能間歇出現，難以重現。
Lease、Static mapping 與故障責任變得不清楚。

因此，在 OpenWrt作為唯一 Router 的設計中，應明確維持：

OpenWrt：DHCP Server 開啟
UniFi Network／其他設備：DHCP Server 關閉

八、故障定位方式¶

無法看到或連上 SSID¶

優先檢查：

AP 電源與 Ethernet link。
Radio 是否啟用。
SSID 是否已 provision。
Security mode 與密碼。

已連上 Wi-Fi，但拿不到 IP¶

優先檢查：

AP bridge／VLAN mapping。
Switch port native／tagged VLAN。
OpenWrt DHCP 是否正常。
DHCP broadcast 是否能通過整條 Layer-2 路徑。

已取得 IP，但不能上網¶

優先檢查：

Default gateway。
DNS。
OpenWrt WAN。
NAT 與 firewall。
VLAN forwarding policy。

只有 Controller UI 無法使用¶

若既有 Wi-Fi 與 Internet 都正常，問題大多位於管理平面，不應直接判定 AP data plane 或 OpenWrt routing 已故障。

九、變更與維護原則¶

初次 Adoption¶

先建立與現況相容的 SSID、安全模式與 VLAN。
第一次遷移不要同時啟用多項進階功能。
Adoption 完成後確認 AP 已 Online 並完成 provisioning。
驗證 Client 能取得正確 DHCP、gateway、DNS 並連上 Internet。
完成後匯出 Controller 設定備份。

Controller 維護¶

維護前確認 AP 已保存有效設定。
Controller 停止期間不要 reset AP。
升級前備份 Controller 設定與資料庫。
升級後驗證 AP inform、provisioning 與管理 UI。

避免遠端 Lockout¶

變更 Router、Firewall、VLAN 或 AP 前，先建立並實測 out-of-band 管理路徑。
將 AP、Controller 與 Router 變更分開進行。
每一步都驗證並保留 rollback。

十、這套分工的優點¶

故障隔離¶

Controller 升級或維護不會直接中斷 OpenWrt routing。

單一責任¶

Gateway、NAT、firewall、DHCP 與 DNS 都有明確負責者。

可替換性¶

可更換 AP 或 Controller，而不必重做整個 Router 架構。

容易診斷¶

可以依照 Layer 1／2、Wi-Fi access、DHCP／DNS、routing 與 management plane 分層排查，而不是把所有問題都歸因於「Wi-Fi 壞了」。

常見誤解¶

誤解一：Controller 停止，Wi-Fi 一定立即中斷¶

修正：已完成 provisioning 的 AP 通常保留最後一次有效設定，基本 bridge forwarding 可繼續運作。

誤解二：UniFi Network 裡填了 Gateway，所以 UniFi 就是 Router¶

修正：Network metadata 描述網路，不代表 Controller 實際提供 routing、NAT 或 DHCP。

誤解三：AP 能設定 VLAN，所以 AP 負責跨 VLAN Routing¶

修正：AP 可對流量分類或加 tag；跨 VLAN routing 與 firewall policy 通常仍由 OpenWrt處理。

誤解四：Controller 不在 Data Path，所以不需要備份¶

修正：Controller 保存 adoption、provisioning 與管理設定。遺失後雖不一定立即中斷流量，但會增加後續維護與復原成本。

理解確認紀錄¶

Kent 已能用自己的話說明：

既有 Wi-Fi Client 在 Controller 停止後仍能上網，是因為 OpenWrt仍是 Router，而已 provision 的 AP 保存並執行既有設定。
Controller 停止後主要失去的是 AP 的集中管理、監控、設定變更與 provisioning 功能。

來源與驗證範圍¶

本文依據 Kent 與 Hermes 對 OpenWrt、UniFi Controller 與 AP Adoption 的既有討論，以及實際完成 adoption、provisioning、網路角色確認與故障邊界驗證的操作紀錄重新整理。Controller 離線行為以已完成 provisioning 的一般 AP 架構為適用條件，不延伸保證依賴 Controller 的進階功能。

本文只提取通用架構與故障判斷，不公開私人網路位址、SSID、設備識別碼、管理入口、帳號、密碼、VPN 設定或 Container 內部路徑。