type
status
date
slug
summary
tags
category
icon
password
在之前配置好家庭网络环境后，稳定运行了很久，大致上也基本满足日常需要，但是还有一些小的问题需要去解决。之前使用的是Dae + MosDNS配置，由DAE劫持流量进行最后的分流和代理，MosDNS主要用于DNS的并发请求和使用DOH、DOT服务，同时也负责DNS去广告。在使用过程中，由于MosDNS的队列化和无图形界面配置，进行特殊规则配置过于麻烦，最终决定还是在整体的DNS链路中增加AdGuard Home单独负责去广告和相关特殊规则的指定，MosDNS仅作为DNS转发器使用，不再兼顾过滤器的作用。
由于Dae的DNS处理方式与OpenClash、Singbox等不同，是通过劫持流量方式实现，无法直接指定端口进行DNS劫持，所以主要的配置部分在于Dae，MosDNS与AdGuard Home的配置部分基本维持原有配置即可。
另一个配置前提：由于我在主路由RouterOS上已经使用ospf进行了国内外流量的分流，所以此教程可能不一定适合于完全使用Dae进行分流的用户，如果存在分流错误等问题，可以尝试修改
Global配置中的连接选项为domain++模式。📝 Dae配置部分
Daed安装
其实这部分说明文档里面已经很完善，可以参考Github上的教程。我自己使用的是Daed，目前最新的Daed版本是
0.9.0版本。相比于Dae，Daed提供一个可视化的网页管理面板，日常进行自定义配置时候更为方便一些。在资源占用上，Daed相比Dae占用的内存要多一些，大概多出100mb左右。Debian或者Ubuntu安装执行如下命令：
其他系统可参考：
getting-started.md
daeuniverse
Global配置
连接选项使用
domain模式，其他无需修改。不需要使用Dae的domain+及domain++ 模式。DNS
由于处理DNS分流和解析不再由Dae负责，所以DNS部分的配置非常简单：
其中adg即AdGuard Home，配置为AdGuard Home监听的地址和端口。此处我使用的默认53端口，如果53端口已经被占用或者存在其他问题，可替换为其他非标端口。
路由部分
路由部分需要在原有的配置基础上，对AdGuard Home进程、MosDNS进程以及系统默认的NetworkManager进程使用
direct(must)规则特殊处理，从而避免产生路由回环。同时，为了在AdGuardHome中可以正确的显示各设备的IP地址，需要对
geoip:private 规则进行修改，使用direct(must)规则。如果使用的是direct规则，那么在AdGuard Home中显示的设备信息均为localhost(127.0.0.1)Route整体规则
整体规则大致如下，里面有一些自定义的配置，可以根据自己需要进行删减。
direct与direct(must)区别
must_rules表示不将DNS流量重定向到dae并继续匹配。对于单一规则，direct和must_direct的区别在于direct会劫持和处理DNS请求（用于流量分割使用），但must_direct不会。当存在DNS请求的流量循环时，must_direct很有用。must_direct也可以写成direct（must）。在上述配置中，以AdGuard Home为例，即进程AdGuardHome匹配的规则不进行DNS流量的劫持和处理且为直连，由AdGuard Home及其上游进行处理，同时由于规则：
将通过Google DNS的流量使用代理处理，从而避免DNS污染。
📝 AdGuard Home配置部分
AdGuard Home部分没有什么需要特别注意配置的，只需要指定上游DNS为Dae所在机器IP地址即可。需要注意的是，如果使用MosDNS作为Dae的DNS解析服务程序，AdGuard Home中不要指向MosDNS的地址，会造成内存泄露以及高CPU占用。公共DNS服务器可以参考：国内外DNS推荐列表 | Dolingou。
我所使用的MosDNS配置文件可以参考：mosdns-config-with-no-leak
🤗 总结归纳
目前情况良好，暂时没有出现错误问题，且能够更方便的对特定客户端、域名进行放行。
后续
由于AdGuard Home与Dae处于同一台机器，在使用
must_direct规则时会造成DNS泄露问题，但如果使用direct规则，在AdGuard Home中又无法正常识别发出DNS请求的客户端，所以我最终还是选择在PVE中新建一个CT容器（LXC），单独负责AdGuard Home和Tailscale。AdGuard Home的上游DNS指向Dae所在的内网IP地址，同时在Dae中，对private部分规则使用direct规则，既满足避免DNS泄露的需要，又满足对各客户端DNS请求的管理。这也是我第一次使用LXC，CT模板使用的是alpine，目前对效能感到满意，在未开启AdGuard Home时，CPU占用几乎没有，内存占用13MB左右，开启AdGuard Home的情况下，单核CPU占用0.4%，内存占用不到50MB。
在使用局域网其他机器作为DNS入口时，需要在Dae的
Routing中增加以下配置，避免DNS请求环路，将下面的10.0.0.20 替换为你的DNS服务入口IP地址。我自身配置问题，与Daed无关，配置正确情况下，未发现Daed出现内存泄露情况。同时初始内存占用也没有1G。
另外，如果使用其他机器作为DNS入口，那么其指向的DNS应为Dae所在机器的IP，不要直接指向MosDNS，由Dae再指向MosDNS，避免DNS重复劫持，造成内存泄露与CPU高占用，配置文件大致如下：
AdGuard Home中的上游DNS指向Dae所在机器IP，同时Dae的DNS部分配置指向MosDNS端口
关于AdGuard Home的卸载
由于已经在LXC容器中单独部署了AdGuard Home，所以原来Debian机器上的AdGuard Home就可以卸载了，首先找到AdGuard Home二进制文件的位置，Debian/Ubuntu系统的位置一般位于
/opt/AdGuardHome执行以下命令注销AdGuard Home相关服务
删除AdGuard Home工作文件夹
📎 参考文章
有关AdGuard Home安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~