AdGuard Home + SmartDNS 安裝教學

架設一個內網測速伺服器。

內網測速,可以測出軟路由的「硬體與網卡極限」,但無法測出對外寬頻的極限。

測試軟路由的 CPU 處理能力、PCIe 通道頻寬、以及網口(比如 2.5G 網卡)的極限傳輸速率。

LibreSpeed 內網測速工具,非常適合用來測試 Wi-Fi 的實際無線傳輸極限與訊號穩定度。

架設一個屬於自己的內網測速伺服器非常簡單,最方便的方式就是透過 Docker 來部署。

所有命令全部複製,貼上執行即可
docker run -d \
--name librespeed \
-p 8989:80 \
--restart unless-stopped \
linuxserver/librespeed





打開瀏覽器,輸入:
http://192.168.36.1:8989

區網有線測試,內網跑滿2.5G 沒有問題。



手機連接WIFI5 AP










iStore內建軟體也有內網測速工具



cazzx wrote:
這樣會有第一篇說的問題,因為是透過 192.168.36.1 轉發 #8053,紀錄的 IP 會是 127.0.0.1,如果要紀錄為 10.0.0.2,要再次劫持 DNS,源區域選 WireGuard(恕刪)



你的方法可行,厲害。

針對 WireGuard VPN 的用戶,AGH 顯示用戶IP。

端口轉發除了原來那條再增加一條規則。








我也是照你教學設定的


不過那篇留言有一點沒說清楚,VPN 進入的源區域是 WireGuard 目標是 192.168.36.1:53,然後 dnsmasq 轉送到上游 192.168.36.1:8053,端口轉發 (Port Forwards) 是直接把目標變成上游位址。因為 LuCI 源區域不能多選,所以只能分開寫,或者自訂防火牆規則 fw4

看了樓主的文章後,我又有信心使用SmartDNS套件了!
底下是僅僅用單一DNS並盡量強制區網內3C都由上述套件查詢,畢竟新手從單一DNS入手比較容易。

底下德國DNS優點如下
https://github.com/hagezi/dns-servers#full-servers
另外,由於我使用HTTPs3,所以查詢速度蠻快。

由於LG、小米、三星、TCL、、、、等3C大廠有海量工程師,底下做法只能防君子不防小人!

我家使用國際牌電視(安卓系統14),用WiFi 5GHz 通道52 頻寬80M。
我在chatGPT協助下已經讓我家區網的3C設備盡量經由路由器的SmartDNS套件查詢。
底下是我叫GPT整理的步驟,重點在於每次重啟Smart DNS後,要等待一分鐘以上,並在TV或PC確認可以正常查詢DNS,才算是重啟完成!


我給GPT的提示:
列出ImmortalWrt 25.12恢復原廠設定後,完成下列工作的Bash指令,並評估是否能讓區網的各種3C設備都由SmartDNS送出查詢!
(路由器是Tplink Ax23)

1、用Ssh進入 ImmortalWrt後,檢測目前防火牆版本。如果是FW3,則移除FW3,並安裝FW4。當防火牆改為FW4或原本就是FW4,則先啟動「軟體流量卸載」,再去做第二點工作。

2、將Wan的DNS改為8.8.8.8和8.8.4.4,而Wan6的DNS維持自動模式。

3、安裝Smart DNS,並啟動「自動調整DNSmasq設定」。然後,將底下Doh3寫入/etc/smartdns/custom.conf
server-h3 h3://76.76.2.11/x-oisd -host-name x-oisd.freedns.controld.com

4、設定防火牆轉發規則,以便區網的3C設備都經由SmartDNS的Doh3送出查詢。

5、提供檢測「區網的3C設備都經由SmartDNS送出查詢」的Bash指令。

GPT回答:
https://chatgpt.com/s/t_6abc8eed171881918d21cd53e8d54f31
別信賴瑞隆8088、台灣財經網紅(李O修、陳O銘、、)!

解決AGH 延遲時間異常





AGH 用戶當中有一個 127.0.0.1

是來自於軟路由系統本機(127.0.0.1)在背景為 SmartDNS 進行「並行查詢、測速與定時刷新快取」所產生的。

除了 SmartDNS 外,軟路由系統本機(127.0.0.1)在背景也會有其他應用程式或系統元件在不眠不休地發起 DNS 查詢,例如DDNS、系統安全與防火牆更新、NTP 校時(網路時間同步)、BT........等等。

如果有「強迫症」,想讓記錄看起來乾淨一點









設定完儲存




這個設定只是「不顯示」和「不統計」而已,軟路由本機的所有 DNS 分流、過濾廣告、依然在後台 100% 正常運作,沒有受到任何影響。

把軟路由自身的流量忽略後,AGH 查詢記錄裡就只會留下家裡「真正的設備」(例如桌電、手機、筆電)所發出的 DNS 請求。想要排查或是封鎖廣告時,變得非常容易閱讀。




SmartDNS 跑在軟路由本機(127.0.0.1),AGH 會把「SmartDNS 自己在背景一邊測速、一邊等待」的超長秒數,全部記錄進統計圖表中。
這指的是 SmartDNS 的 「過期快取」 或是 「過期快取雙重確認」 功能。這個機制通常被稱為 「過期快取 (Stale Cache)」 或是其核心的 「背景自動重新整理 / 非同步測速」 機制。

SmartDNS 非常聰明,當它發現某個網站你經常造訪,在快取過期之前,它會在背景偷偷自動幫你重新查詢並更新紀錄。這意味著你日常常用的大多數網站,永遠都處於「0延遲」的秒開狀態。

結果就是AGH 面板上顯示的平均處理時間(延遲)被拉高到上百毫秒,看起來非常驚人。

忽略掉以後就不會出現很離譜的延遲時間,恢復正常,才能顯示真正的延遲時間。


針對DNS洩漏跟DNS劫持,Smartdns 的上游伺服器,必須刪除中華電信的DNS ,並全面改用加密的DNS。

DNS 加密最大的好處是「防竄改」與「防劫持」,確保你的網址解析不會被中間人偷換成釣魚網站。

加密DNS+AGH防釣魚清單的組合,能擋下「絕大部分已知的假網站」,最後一道防線還是得靠你自己——收到EMAIL簡訊或 LINE 的不明連結時,保持警覺,先確認網址拼法正不正確再點擊。

預設組(台灣本土與一般國外網站)

【名稱】Cloudflare IPv4
【ip】 https://1.1.1.1/dns-query
【類型】https
【組別】default

【名稱】Google IPv4
【ip】 https://8.8.8.8/dns-query
【類型】https
【組別】default

【名稱】TWNIC Quad101 IPv4
【ip】 https://101.101.101.101/dns-query
【類型】https
【組別】default

【名稱】Cloudflare IPv6
【ip】 https://[2606:4700:4700::1111]/dns-query
【類型】https
【組別】default

【名稱】Google IPv6
【ip】 https://[2001:4860:4860::8888]/dns-query
【類型】https
【組別】default


【名稱】TWNIC Quad101 IPv6
【ip】 https://[2001:de4::101]/dns-query
【類型】https
【組別】default

【名稱】TWNIC Quad101 IPv6
【ip】 https://[2001:de4::102]/dns-query
【類型】https
【組別】default


China 組(專攻中國大陸網站),高級設置中的从默认组中排除記得打勾

【名稱】Ali DNS IPv4
【ip】 https://223.5.5.5/dns-query
【類型】https
【組別】China

【名稱】Tencent DNS IPv4
【ip】 https://1.12.12.12/dns-query
// 註:這條是騰訊 DNSPod 官方加密接口
【類型】https
【組別】China


【名稱】Ali DNS IPv6
【ip】 https://[2400:3200::1]/dns-query
【類型】https
【組別】China

【名稱】Tencent DNS IPv6
【ip】 https://[2402:4e00::]/dns-query
【類型】https
// 註:此為騰訊公共 IPv6 DoH 標準規格
【組別】China


Special 組 (針對本土DNS封鎖的爭議性網站),高級設置中的从默认组中排除記得打勾

【名稱】Cloudflare IPv4
【ip】 https://1.1.1.1/dns-query
【類型】https
【組別】Special

【名稱】Google IPv4
【ip】 https://8.8.8.8/dns-query
【類型】https
【組別】Special

【名稱】Cloudflare IPv6
【ip】 https://[2606:4700:4700::1111]/dns-query
【類型】https
【組別】Special

【名稱】Google IPv6
【ip】 https://[2001:4860:4860::8888]/dns-query
【類型】https
【組別】Special





日常一般網站:由預設組的 TWNIC、Cloudflare 與 Google 共同測速,挑選延遲最低的節點。

中國大陸網站:由 China_List 自動分流至阿里與騰訊 DNS。

被本土屏蔽的網站:由 Special_List 交給純淨的 Cloudflare 與 Google 加密 DNS 解析,完美繞過封鎖。

確認 China 與 Special 上游已从默认组中排除






因為我的Smartdns 有使用ivp6 ,所以有加入ivp6的加密DNS ,如果沒有使用ivp6 加入ivp4的dns 就可以了。

SmartDNS 最厲害的殺手鐧,就是透過它的「雙棧並行查詢」與「測速機制」來完美填補 IPv6 的天生缺陷。

傳統的網路環境中,瀏覽器遇到同時擁有 IPv4 與 IPv6 的網站時,預設動作是「不管三七二十一,先走 IPv6 看看」。如果那條 IPv6 線路剛好繞遠路或中斷,瀏覽器就會傻傻等個幾秒鐘直到連線逾時,才甘願切換回 IPv4,這就是感受到「卡頓、轉圈圈」的元凶。

有了 SmartDNS 之後,整個邏輯被徹底翻轉了。

透過這樣的機制,你既能享受 IPv6 帶來的好處(例如讓 BT 瞬間取得真實公網 IP 飆升下載速度,確實快很多),又完美避開了日常瀏覽網頁、看影片時可能踩到的 IPv6 卡頓地雷。


ipv6 測試網頁





smartdns 確實拿到IPV4跟IPV6的IP
Windows 終端機中
nslookup youtube.com
nslookup google.com






mullvad DNS洩漏測試




完全沒有洩漏!這是一個非常完美且成功的 100% 安全結果!
它的紅色只是在提醒你「目前沒有連上 Mullvad 品牌的 VPN 服務」,並不是指你的隱私洩漏了。
供應商(ISP)全數顯示為「Google LLC」:這代表你家所有的 DNS 查詢請求,全部都活在你設定的 Google 加密通道(DoH/DoT)保護傘下。
完全沒有出現任何一條「中華電信(Chunghwa Telecom)」或台灣當地其他明文 ISP 的名字。這代表不論是你的電信商、社區寬頻廠商還是路上的駭客,現在完全無法窺探你點擊了哪些網址。


https://www.dnsleaktest.com
如果測試結果顯示了你原本 ISP 的名稱或國籍,就代表發生了洩漏。
SmartDNS 正在完美發揮「優選最快路徑」的功能。
Cloudflare 和 Google 連接台北的節點,我在台北的隔壁縣市。
沒有顯示Hinet 代表DNS 沒有洩漏。



你的隱私現在安全了,你不會被假網站騙了。

加密 DNS需要為每次的查詢或連線進行 SSL/TLS 握手憑證驗證,延遲會高一點。
第一次稍慢,其實也感覺不出來,得益於SMARTDNS快取與測速,延遲會越用越低。




https://adblock-tester.com/






如果你有在使用IPV6 ,瀏覽器可以安裝擴充套件,能顯示你瀏覽的網頁是走IVP4還是IPV6的

Chrome 線上應用程式商店,搜尋IPvFoo



裝好會在瀏覽器右上角顯示數字

點擊數字,可以看到這個網頁組件,各自使用IPV4或是IPV6



(開頭是 2001: 或 2404: 的長地址):包含負責載入帳號資訊的 accounts.youtube.com,以及最吃頻寬、負責傳輸影片畫面的核心 CDN 伺服器(那些 rr1---sn、rr3---sn 開頭的網址)。

走 IPv4 (開頭是 142.25x.x.x 的短地址):包含 YouTube 的網頁主框架、負責載入字體的 fonts.gstatic.com,還有一些縮圖伺服器 i.ytimg.com。





Windows 系統層級將 Chrome 的安全 DNS 政策寫死為關閉
打開終端機(系統管理員)



輸入下面指令
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v DnsOverHttpsMode /t REG_SZ /d "off" /f



徹底關閉 Microsoft Edge 的內建安全 DNS,確保流量完全導向你的軟路由
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsMode /t REG_SZ /d "off" /f





徹底關閉 Firefox 的內建 DNS(DNS over HTTPS, DoH),確保所有流量都乖乖經過你的軟路由與 SmartDNS
在 Firefox 網址列輸入 about:config 並按下 Enter。如果出現警告畫面,請點擊「接受風險並繼續」。
在上方的搜尋列輸入 network.trr.mode。
點擊右側的編輯按鈕(或直接連點兩下該項目),將數值修改為 5,然後按下 Enter 或點擊打勾儲存。

安裝 Wireguard VPN


更新清單,軟件包中搜尋 wirdguaed ,ISTORE內已經預安裝好,有最新版 按升級最新版本




接著搜尋 qrencode 並點擊 安裝



重新啟動軟路由

前往 網絡 → 接口 → 添加新接口
名稱輸入 wg0,協議選擇 WireGuard VPN,點擊 創建接口。



在常規設置中

點擊 生成新的密鑰

監聽端口輸入 51820(或自訂一個 1024 以上的端口號)。

IP 地址輸入一個不與家中現有網段衝突的虛擬 IP,例如家中若是 192.168.1.x,這裡可填 10.0.0.1/24




在同一個設定視窗上方,切換至 防火牆設置

创建/分配防火墙区域 選擇Lan




切換至上方的 對端分頁,點擊 添加對端。

描述:輸入設備名稱(例如 三星M33)。

點擊 生成新的密鑰對,以及點擊 生成預共享密鑰提升安全性。

允許的 IP(Allowed IPs):輸入分配給這支手機的專屬虛擬 IP,例如 10.0.0.2/32(結尾請填 /32 代表單一設備)

勾選 路由允許的 IP

點擊右下角 保存、保存,回到接口主畫面後點擊 保存並應用






設定防火牆放行端口
前往 網絡→ 防火牆→ 通信規則,拉到最下方點擊 添加。
名稱:Allow-WireGuard
協議:選擇 UDP
源區域:選擇 wan
目標區域:選擇 設備輸入
目標端口:輸入 51820
操作:選擇 接受
點擊 保存,再點擊 保存並應用。




回到 網絡 → 接口,點擊 wg0 右側的 編輯,切換到 對端分頁。








打開手機 wireguard app 使用掃描 QRCODE 的方式加入,完成。

OpenWrt 路由器上設定讓手機透過 USB 連接線分享網路


iStoreOS 已經預先安裝好手機的驅動,不需要安裝驅動。

準備一條支援傳輸功能的 USB 線,將手機接上 OpenWrt 路由器的 USB 連接埠。

開啟網路共享


openwrt 進入後台 網絡---接口----添加新接口

名稱 WAN_USB

協議 DHCP客戶端

設備 usb0




切換到上方的高級設置,自動獲取DNS服務器取消打勾





切換到上方的 防火牆設定,將防火牆區域指定為 wan



右下角保存,回到接口介面右下角 保存並應用

重啟軟路由

重啟後,到網路---接口---將wan 接口右方 按停止




手機接上軟路由USB 然後手機開啟USB共享網路

同樣享有AGH+SMARTDNS功能




SQM 新增一個連接,讓5G網路延遲好看一點






終結 IoT 與 IPCAM 設備「寫死 DNS」偷跑外網!


iStoreOS / OpenWrt 強制轉回軟路由 AdGuard Home

家裡部署了軟路由(如 iStoreOS / OpenWrt) 並架設 AdGuard Home 後,很多人會發現一個奇怪的現象:明明已經在 DHCP 分配了軟路由的 DNS,為什麼家裡的 智慧家電(IoT)、網路攝影機(IPCAM)、智慧電視或機上盒,在 AdGuard Home 的查詢日誌裡卻很少出現,或是攔截規則對它們完全失效?

這些設備在韌體裡「寫死(Hardcode)」了外部 DNS(例如直接寫死 8.8.8.8、114.114.114.114、223.5.5.5 或外部 IPv6 DNS)。它們根本不理會 DHCP 派發的設定,而是直接把 Port 53 請求往外網(WAN)送,徹底繞過軟路由的過濾與監控。

雖然這些公共 DNS 本身並非惡意伺服器,但廠商寫死它們的主要目的,是為了繞過用戶在路由器 DHCP 配發的本地廣告與追蹤攔截器(如 AdGuard Home、Pi-hole)。

本地黑名單就無法將其解析為空值(0.0.0.0)。設備取得真實 IP 後,便能暢行無阻地回傳設備狀態、連線紀錄、觀看習慣,甚至是區網內其他設備的掃描清單。

部分白牌 IP Cam 或低價跨境 IoT 設備,寫死的並非知名公共 DNS,而是廠商自建或來路不明的私有 DNS IP。

私有 DNS 能完整記錄設備的活躍時間與所有連線意圖。

該 DNS 可以將原本正常的服務請求(如 NTP 校時、韌體更新、P2P 穿透連線)刻意解析到具備資料收集或監控功能的伺服器。

若小廠倒閉、伺服器 IP 釋出或網域過期被駭客搶註,所有寫死該設定的設備會直接被導向惡意控制端(C2 Server),淪為殭屍網路(Botnet)或肉雞。

以下分享如何透過防火牆的 「端口轉發」 搭配 「通信規則」,雙管齊下把這些不聽話的 IoT 與 IPCAM 設備全部抓回軟路由的 AdGuard Home 管控!

要徹底收服寫死 DNS 的設備,必須同時處理 IPv4 轉發 與 IPv6 阻斷:

端口轉發(攔截並導回 AdGuard Home):當內網(LAN)設備試圖對外網(WAN)的任意公共 DNS 發起 Port 53 請求時,在防火牆半路攔截,強制將流量重定向回軟路由內部的 AdGuard Home 監聽端口( 8053)。

通信規則(封堵 IPv6 繞過漏洞):現代許多智慧設備支援雙棧網路(IPv4/IPv6),若設備寫死外部 IPv6 DNS,會繞過 IPv4 的轉發規則。透過通信規則將往外網(WAN)的 IPv6 Port 53 流量直接「拒絕(Reject)」,能逼迫設備瞬間放棄外部 IPv6 DNS,乖乖退回走受軟路由管控的通道。

設定「端口轉發」(強制將外部 DNS 請求導回軟路由)



針對內部沒有寫死 DNS、乖乖走 DHCP 的設備,它們本來就會把請求送往 lan;但對於強制寫死外部 DNS 的 IoT 與 IPCAM 設備,它們的封包目標是外網 IP,因此這裡攔截往 wan 方向走的 Port 53 流量,並直接轉發到軟路由的 192.168.36.1:8053,設備即使在背景狂問 8.8.8.8,實際上回答它的都是你自己的 AdGuard Home!

設定「通信規則」(阻斷寫死 IPv6 DNS 偷跑外網)



選擇 拒絕 時,防火牆會立刻向設備回傳 ICMPv6 拒絕訊號。IoT 設備或手機一收到「此路不通」的明確通知,會在幾毫秒內立刻切換回 IPv4,轉而進入我們在第一步設好的 8053 端口轉發通道;如果選「丟棄(Drop)」,設備會傻傻等待連線逾時(Timeout),反而造成連線卡頓或畫面載入變慢。

在台灣OPENWRT上建立一個翻牆伺服器節點


OpenWrt 軟路由上架設 Sing-box 服務端(使用抗封鎖能力最強的 VLESS + REALITY 協議)。

REALITY 協議會把流量偽裝成連往大型合法網站的 TLS 流量,不僅沒有特徵、不需自己買域名,還能完美避開 GFW 的封鎖。

開始前,請確保你的台灣軟路由具備 公網 IP(建議設好 DDNS 動態域名)

透過 SSH 安裝原生 Sing-box 核心


更新軟體源並安裝 sing-box

apk update && apk add sing-box
註:如果你的 OpenWrt / iStoreOS 為舊版系統,請改用傳統指令:opkg update && opkg install sing-box



依序執行以下三行指令,產生專屬的 UUID、REALITY 金鑰對 與 Short ID(請將畫面輸出的結果複製到記事本保存):

sing-box generate uuid
sing-box generate reality-keypair
sing-box generate rand --hex 4







接著建立服務端設定檔。請先將下方整段指令複製到電腦記事本,把裡面的 UUID、PrivateKey 與 Short_ID 替換成剛剛產生的數值(⚠️ 注意:服務端這裡填的是 PrivateKey 私鑰;而 PublicKey 公鑰請留好,下一篇手機客戶端會用到):


cat << 'EOF' > /etc/sing-box/config.json
{
"log": {
"level": "info"
},
"inbounds": [
{
"type": "vless",
"tag": "vless-in",
"listen": "::",
"listen_port": 8443,
"users": [
{
"uuid": "這裡替換為剛剛產生的UUID",
"flow": "xtls-rprx-vision"
}
],
"tls": {
"enabled": true,
"server_name": "itunes.apple.com",
"reality": {
"enabled": true,
"handshake": {
"server": "itunes.apple.com",
"server_port": 443
},
"private_key": "這裡替換為剛剛產生的PrivateKey",
"short_id": [
"這裡替換為剛剛產生的8位數Short_ID"
]
}
}
}
],
"outbounds": [
{
"type": "direct",
"tag": "direct"
}
]
}
EOF


修改完以後,整段複製貼到終端SSH裡面後按ENTER
請確認最後一行的 EOF 有被執行、畫面跳回 root@iStoreOS:~# 提示字元,才算寫入成功



啟動系統服務,在終端中輸入以下命令



uci set sing-box.main.enabled='1'
uci set sing-box.main.user='root'
uci commit sing-box
/etc/init.d/sing-box enable
/etc/init.d/sing-box restart




開放 OpenWrt WAN 防火牆端口:

回到 OpenWrt 網頁後台 ➔ 網路 ➔ 防火牆 ➔ 通信規則 。

添加一條新規則

名稱:Allow-SingBox

協定:TCP

來源區域:wan

目標區域:設備 (輸入) / Device (input)

目標端口:8443(對應你設定的 listen_port)

動作:接受
右下角保存---------保存並應用



服務端架設完成
關閉廣告
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!