OPENWRT升級和安裝軟體綜合討論串

我將TP-Link Archer AX23 刷成 OpenWrt
Current stable release - OpenWrt
https://openwrt.org/releases/start

個人做法供參：
2.4GHz: 802.11 AX 20MHZ 頻道 1
5GHz: 802.11 AX 80MHZ 頻道 48
2.4Ghz的重點在於發射距離越遠越好，所以才建議用40M頻寬，甚至用20M！
5Ghz的重點在於網路頻寬越大越好，所以才建議用80M頻寬，甚至用160M！

啓用HTTPS DNS proxy
服務狀態
版本2025.10.07-r1 - 執行中
強制使用指定DNS連接埠： 53 853.
服務實例
Custom (https://v.recipes/dns/freedns.controld.com/x-hagezi-proplus)代理，位於連接埠5053.

網路 - 防火牆 - 區域設定 - 一般設定
啟用SYN洪水保護
丟棄無效封包

網路 - 全域網路選項 - 封包引導
已啟用（所有CPU）

網路 - 防火牆 - 防火墻路由卸載》軟體流量卸載

設好后，在Window Terminal執行ipconfig/flushdns，就能重置DNS。

PS：
谷歌AI說：
1. 軟體流量卸載 (Software Flow Offloading)
軟體流量卸載是透過 Linux 核心中的 nftables 或 iptables 建立一條「快速路徑」，讓已建立連線的封包繞過複雜的核心網路堆疊（Network Stack）。
優點：
通用性高：幾乎支援所有網路介面（LAN, WAN, Wi-Fi）。
效能提升顯著：能將轉發效能提升約 2-3 倍，讓 MT7621 處理近 500-600Mbps 的流量時 CPU 負擔減輕。
相容性較好：比硬體卸載穩定，較少出現連線中斷或 Wi-Fi 異常問題。

2. 硬體流量卸載 (Hardware Flow Offloading)
這是利用 MT7621 內建的硬體封包處理引擎（PPE / Hardware NAT）來執行任務，封包直接在硬體層面交換，完全不經過 CPU。
缺點：
功能衝突多：與 流量監控（Statistics）、QoS、**大部分插件（如某些科學網際網路插件的過濾功能）**不相容。
特定限制：MT7621 的硬體卸載在 OpenWrt 官方驅動下主要支援 乙太網路 (LAN/WAN)，對 Wi-Fi 的加速效果有限。
潛在 Bug：在某些舊版 OpenWrt 核心上可能導致連線凍結或 iOS 通知推送延遲。

如果你追求極致穩定且頻寬在 500M 以下：
建議：僅開啟「軟體流量卸載」。
這能在提升效能的同時，避免硬體加速可能帶來的特定網路相容性 Bug。
https://gemini.google.com/share/1ba54af7aec2


【轉貼】在 2.4GHz 頻段中，頻道1、6和11是僅有的3個非重疊且干擾最小的頻道。
若在 5G 頻段您有 24 個頻道可以選擇，建議您可以選擇像 36、48、149和161 的頻道。
htthttps://www.tp-link.com/tw/blog/95/%E8%AE%93%E5%AE%B6%E4%B8%ADwi-fi%E5%8F%96%E5%BE%97%E6%9B%B4%E5%BF%AB%E7%B6%B2%E8%B7%AF%E9%80%9F%E5%BA%A6%E7%9A%8410%E5%80%8B%E6%96%B9%E6%B3%95/ps://www.tp-link.com/tw/blog/95/%E8%AE%93%E5%AE%B6%E4%B8%ADwi-fi%E5%8F%96%E5%BE%97%E6%9B%B4%E5%BF%AB%E7%B6%B2%E8%B7%AF%E9%80%9F%E5%BA%A6%E7%9A%8410%E5%80%8B%E6%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 有時會因為判斷邏輯，導致中斷在兩個核心間不斷跳動，造成系統不穩定。


針對 TP-Link Archer AX23 刷成 OpenWrt 後的情況，最適合的DoH 套件是：https-dns-proxy
此因谷歌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) 工作。