2026/3/26 付けでリリースされた OpenWrt の 25.12.2 インストールでのトラブル対応記事になります。全体的な話はこちら。
cube309b.hatenablog.com
トラブル #4：「ブロックされたドメインが 0」問題！
通常、何らかのフィルターを読み込ませるとブロック予定のドメイン数が表示されるのですが、全ての設定が終わっても 0 という状態でした。
これは以前にもあったトラブルで adblock.custom.feeds の記述書式が変更されたことにより、以前の定義をそのままコピーしたりすると無効になってしまうというものです。AI にお願いして 25.x 系での新書式を調べてもらって事なきを得ました。
旧書式 (tofu フィルターの例)
{
"tofu": {
"url": "https://raw.githubusercontent.com/tofukko/filter/master/Adblock_Plus_list.txt",
"rule": "BEGIN{FS=\"[|^]\"}/^\|\|([[:alnum:]_-]{1,63}\.)+[[:alpha:]]+\^(\$third-party)?$/{print tolower($3)}",
"size": "S",
"descr": "ads_analysis"
}
}新書式 (25.x 系)
{
"tofu": {
"url": "https://raw.githubusercontent.com/tofukko/filter/master/Adblock_Plus_list.txt",
"rule": "feed || 3 [|^]",
"size": "S",
"descr": "ads_analysis"
}
}トラブル #5：そもそも tofu フィルターは DNS ベースの環境では効果が薄かった問題！
いろいろ検討した結果以下の記事の通り、日本語環境対応用に tofu フィルターを採用していました。
cube309b.hatenablog.com
ところが今回のトラブル シュートをする中で AI からしれっと一言「tofu フィルターはブラウザ拡張用ルール（CSS 要素非表示）が大半で DNS レベル ブロックにはほぼ無効」と言われてしまいました。これは完全に私の知識不足です。
というわけで DNS 型のブロックで有効そうなフィルターを見繕ってきてもらいました。
No.
フィルター名
提供元
信頼の根拠
1
hagezi
ドイツのセキュリティ研究者 hagezi 氏個人
GitHub 上で最も頻繁に更新される DNS ブロック リストの一つ。コミュニティ レビューも活発。OpenWrt adblock の公式プリセットにも採用
2
certpl
ポーランド政府の CERT
国家機関が運営する公的なフィッシング ドメイン リスト。世界中のフィッシングサイトを収集・公開している
3
phishing_army
Phishing Army プロジェクト
PhishTank、OpenPhish 等の複数の信頼できるソースを統合した老舗リスト。フィッシング対策に特化しており、誤検知率が低い
4
stevenblack
Steven Black 氏個人
GitHub で最も有名なブロック リスト。複数の信頼できるリスト（adaway, malwaredomainlist 等）を統合。10 年以上の運用実績があり、コミュニティが大きい
新書式 (25.x 系) での adblock.custom.feeds の記載は以下の通りとなりました。
{
"hagezi": {
"url": "https://raw.githubusercontent.com/hagezi/dns-blocklists/main/domains/light.txt",
"rule": "feed 1",
"size": "L",
"descr": "compilation"
},
"certpl": {
"url": "https://hole.cert.pl/domains/v2/domains.txt",
"rule": "feed 1",
"size": "L",
"descr": "phishing"
},
"phishing_army": {
"url": "https://phishing.army/download/phishing_army_blocklist_extended.txt",
"rule": "feed 1",
"size": "S",
"descr": "phishing"
},
"stevenblack": {
"url": "https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts",
"rule": "feed 0.0.0.0 2",
"size": "L",
"descr": "compilation"
}
}トラブル #6：インターフェースと adblock の起動タイミングが合わず、フィルターが読まれない問題！
これも以前に遭遇した問題で、OS の再起動等の過程でうまくネットワークが起動しきってない状態で adblock のサービスが起動することでフィルターが読み込まれずやっぱり「ブロックされたドメインが 0」問題が発生します。
任意のタイミングで adblock をリロードすると正常に読み込まれるためやっぱり起動時のタイミングの問題ということになります。以前は rc.local 上で起動遅延を入れて回避していたのですが、フィルターを変えたため時間調整が必要になりました。
単純に時間を延ばしたり、起動するまで非同期のループ処理を入れるなど AI に相談して試したのですが上手く行かず。結局、サービスの基本機能でのインターフェース起動待ちと時間待機という機能で何とか切り抜けました。
uci set adblock.global.adb_trigger="wan6"
uci set adblock.global.adb_triggerdelay="15"wan6 の起動待ちだけで行けると思ったのですがやっぱりだめで更に 15 秒の時間を入れてようやく正常に起動するようになりました。またしても時限式という・・・。
トラブル #7：Azure Monitor 系の名前解決に失敗する問題！ (以前からの継続課題)
「Monitor」という名称からか Azure Monitor で利用しているいくつかのドメインの名前解決に失敗するという問題がありました。フィルターを変更してもやっぱりブロック対象リストに含まれている状態です。
ドメイン単位の許可リストの場合、ワイルドカード「*」が利用できず FQDN で一つ一つ追加する必要があるためしばらく放置してました。どうしても名前解決が必要な場合はノード側で参照 DNS を 8.8.8.8 に変更するといった具合になります。
adblock が dnsmasq の上で動いていることを利用して /etc/dnsmasq.conf にワイルドカード付きで指定して、8.8.8.8 にフォワード出来る事を知りました。AI さまさまです。
uci add_list dhcp.@dnsmasq[0].server="/azure.com/8.8.8.8"
uci add_list dhcp.@dnsmasq[0].server="/microsoft.com/8.8.8.8"
uci add_list dhcp.@dnsmasq[0].server="/visualstudio.com/8.8.8.8"
uci add_list dhcp.@dnsmasq[0].server="/microsoftonline.com/8.8.8.8"トラブル #8：それでも広告ブロックによってスマートフォン ゲームへ影響が出た問題！
ゲーム中で特典を受け取るためなどに広告を見ることがあると思うのですがそれが出来ないと家族より連絡がありました。
スマートフォン ゲームの場合 URL なども簡単には分からないですし、都度ログを見て URL を確認するのも手間だったので端末そのものを広告ブロックの対象外とすることにしました。いわゆるゲーム専用のサブ端末なので問題ないかなと・・・。
uci set adblock.global.adb_nftallow="1"
uci set adblock.global.adb_allowdnsv4="8.8.8.8"
uci set adblock.global.adb_allowdnsv6="2001:4860:4860::8888"
uci add_list adblock.global.adb_nftmacallow="除外したい端末の MAC アドレス"v6 プラスの環境なので端末は IPv6 で名前解決を行うこともあったので、8.8.8.8 だけではなく 2001:4860:4860::8888 というフォワード先を設定するのがポイントになります。
また、最近のスマートフォンは自身の MAC アドレスをランダムに設定する機能があるためそれは事前に切っておきました。MAC アドレスが変わってしまうとこの設定には意味がないので・・・。
AI を活用したトラブル シュートを終えて
自分一人でやったら検証から実装まですごく時間がかかったであろう事が一気に片付きました( ^)o(^ )
Note
・ 当ブログは個人主催であり、ブログ中のすべての情報は個人的な観点となります。
