Current stable release - OpenWrt 24.10.4
https://openwrt.org/releases/24.10/start
個人做法供參：
2.4GHz: 802.11 AX 20MHZ 頻道 1
5GHz: 802.11 AX 80MHZ 頻道 149
2.4Ghz的重點在於發射距離越遠越好，所以才建議用40M頻寬，甚至用20M！
5Ghz的重點在於網路頻寬越大越好，所以才建議用80M頻寬，甚至用160M！
啓用HTTPS DNS proxy
服務狀態
版本2025.10.07-r1 - 執行中
強制使用指定DNS連接埠： 53 853.
服務實例
Custom (
https://v.recipes/dns/freedns.contr...-hagezi-proplus)代理，位於連接埠5053.
啓用AdBlock-Fast
輸出詳細程度設定》抑制輸出，控制系統日誌和主控台輸出的詳細程度。
黑白清單網址》Hagezi-NORMAL-domains
服務狀態
版本 1.2.0-r22 - 活動.
封鎖137259個網域 (用 dnsmasq.servers)。
強制使用指定DNS連接埠： 53 853.
設好后，在Window Terminal執行ipconfig/flushdns
當我的TP-Link Ax23被刷機成Openwrt後，其防火牆的硬體流量卸載被啟動，且我沒有安裝Sqm等QoS套件。
這樣一來，我在下列網站得分是B，且路由器負載（1/5/15分鐘平均值往往低於0.15！）
（如果我關閉硬體流量卸載，且使用SQM，也能拿到B，但路由器負載偏高）
Bufferbloat and Internet Speed Test
https://www.waveform.com/tools/bufferbloat
測速（我在其四種場景共拿到19顆星星）
https://www.speedtest.net/zh-Hant
PS：
【轉貼】在 2.4GHz 頻段中，頻道1、6和11是僅有的3個非重疊且干擾最小的頻道。
若在 5G 頻段您有 24 個頻道可以選擇，建議您可以選擇像 36、48、149和161 的頻道。
https://www.tp-link.com/tw/blog/95/...96%B9%E6%B3%95/
當TP-Link Ax23被刷機成Openwrt後，且我沒有安裝Sqm等QoS套件，其防火牆的硬體流量卸載被啟動，這樣做不會影響Openwrt的HTTPS DNS Proxy套件功能！
此因谷歌AI認爲：
對於 TP-Link AX23 這類路由器（通常使用 MediaTek Filogic 晶片），這其實是最佳配置：
HTTPS DNS Proxy 會消耗一定的 CPU 資源（因為 HTTPS 加密需要運算）。
硬體流量卸載 則會釋放 CPU 資源（不讓 CPU 處理龐大的下載流量）。
開啟硬體卸載反而能騰出更多 CPU 算力給 https-dns-proxy 使用，避免在高流量下載時，因為 CPU 滿載而導致 DNS 解析變慢。
當TP-Link Ax23被刷機成Openwrt後，它不適合使用Irqbalance套件！
此因谷歌AI認爲：
1. 硬體架構特性 (雙核心效益有限)
TP-Link AX23 通常搭載的是一顆 雙核心CPU。
核心數過少： irqbalance 的主要優勢在於多核心（通常是 4 核以上）伺服器環境，能將大量的中斷請求（Interrupts）動態分配給不同的 CPU 核心處理。但在僅有雙核心的嵌入式設備上，中斷分配的選擇非常有限（不是 Core 0 就是 Core 1），動態調整的效益極低。
預設綁定已足夠： 現代 OpenWrt 的 MediaTek 目標（Target）驅動程式通常已經針對雙核心進行了優化，預設的中斷親和性（SMP Affinity）通常已經設定得足夠好。
2. 硬體卸載 (Hardware Offloading) 的存在
這是最關鍵的理由。MediaTek MT7621擁有強大的 封包處理引擎 (PPE, Packet Process Engine)，也就是俗稱的硬體 NAT。
繞過 CPU： 當你在 OpenWrt 的防火牆設定中啟用「軟體流量卸載 (Software Flow Offloading)」與「硬體流量卸載 (Hardware Flow Offloading)」後，大部分的網路封包轉發工作會由專用的硬體晶片處理，根本不需要 CPU 介入。
中斷減少： 既然 CPU 不需要處理這些封包，產生的中斷（IRQ）數量就會大幅下降。此時 irqbalance 就沒有用武之地，因為根本沒有高負載需要「平衡」。
3. 快取震盪 (Cache Thrashing) 與延遲
在嵌入式系統中，頻繁地將中斷處理在不同的 CPU 核心之間搬移，反而會造成負面影響：
快取失效： 當中斷從 Core 0 被搬移到 Core 1 時，Core 0 原本 L1/L2 Cache 中的相關資料就會失效，Core 1 必須重新載入資料。這會導致 CPU 週期浪費，反而增加了網路延遲（Latency）。
抖動問題： irqbalance 有時會因為判斷邏輯，導致中斷在兩個核心間不斷跳動，造成系統不穩定。
[B]
針對 TP-Link Archer AX23 刷成 OpenWrt 後的情況，最適合的DoH 套件是：https-dns-proxy [/B]
此因谷歌AI認爲：
1. 硬體資源的極限 (最關鍵理由)
根據 OpenWrt 的硬體資料庫，TP-Link Archer AX23 (v1) 的核心規格如下：
CPU: MediaTek MT7621DAT (雙核心 MIPS 架構, 880MHz)
RAM: 128 MB (DDR3)
Flash (儲存空間): 16 MB (SPI-NOR)
這個規格在現代標準下屬於「入門級」。
儲存空間僅 16MB： 這是最大的瓶頸。OpenWrt 系統本身已佔用大部分空間，剩下的可用空間極少。SmartDNS 的體積相對較大，而 AdGuard Home 等軟體動輒十幾 MB，幾乎不可能直接安裝在內建 Flash 中。而 https-dns-proxy 的安裝檔非常輕量（僅約幾十 KB），完全不會對儲存空間造成壓力。
記憶體僅 128MB： 執行 DoH 加密運算需要消耗 RAM。https-dns-proxy 設計極為精簡，常駐記憶體極低。相比之下，如果使用更複雜的 DNS 套件，可能會在併發連線數高時導致記憶體耗盡 (OOM)，造成路由器當機或重啟。
2. 架構與整合性
原生整合 Dnsmasq： OpenWrt 預設使用 Dnsmasq 作為 DNS 解析器。https-dns-proxy 的設計邏輯是「輔助」而非「取代」。它會在後台建立一個輕量的本地 DoH 代理 (Localhost proxy)，讓原本的 Dnsmasq 將查詢轉發給它處理。這種架構最符合 OpenWrt 的原生設計邏輯，穩定性最高。
MT7621 的效能負擔： 這顆 CPU 雖然是雙核心，但屬於較舊的 MIPS 架構。在處理高強度的 HTTPS 加密封包時（DoH 本質就是 HTTPS），CPU 負擔不小。https-dns-proxy 相對單純，專注於轉發與加密，沒有多餘的功能（如複雜的廣|告過濾規則比對），能將 CPU 資源留給更重要的封包轉發 (NAT) 工作。