俺的 Linux 网络环境实践（在 NixOS 上基于 dae 的网卡级代理配置）

问题描述：

俺用了 nixos 也有一段时间了，配置网络环境的时候踩了不少坑，以下是俺的记录（在很多地方俺还是新手，所以本文仅作为记录，希望对大家有参考价值）。

俺一开始用的是 Clash Verge Rev 来进行代理，但是遇到了以下问题：

• programs.clash-verge.tunMode 选项不能正常工作，不清楚什么问题，并且打开之后总是卡死
• 某个时间之后图形界面不能正常显示，俺的 wm 是 niri，wayland 环境，或许 tauri 在这上面有些问题。
• 由于上面的原因，俺打不开 tun，平时浏览器用 proxy switchyomega，终端设置环境变量把流量导到代理上，勉强能用，但是 nix 的 daemon 不会鸟我的环境变量（见 使用代理工具加速访问 Channels 跟 Flake Inputs），每次都很麻烦，对于 docker 同理。

FlClash 之类的客户端存在差不多的问题（tun 俺搞不定），再加上不太符合 nixos 纯函数式 OS as Code 的理念，所以俺不太喜欢用。

后来俺知道了 dae 这个工具，它是一个高性能的透明代理解决方案，利用 eBPF 在内核里面实现流量分流拆分与透明代理，所以相比其他软件，直连和分流性能都会更高。

因为 dae 不支持更新订阅（daed 不在讨论范围内），俺一开始是写一个 bash 脚本用 curl 下载订阅：

{ config, lib, pkgs, inputs, ... }: { age.secrets.dae-sub = { file = ../../secrets/dae-sub.age; path = "/etc/dae/sublist"; symlink = false; }; systemd.timers."update-subs" = { wantedBy = [ "timers.target" ]; timerConfig = { OnBootSec = "5m"; OnUnitActiveSec = "12h"; Unit = "update-subs.service"; }; }; systemd.services."update-subs" = { script = '' #!/usr/bin/env nix-shell cd /etc/dae || exit 1 version="$(${inputs.daeuniverse.packages.x86_64-linux.dae}/bin/dae --version | head -n 1 | sed 's/dae version //')" UA="dae/$version (like v2rayA/1.0 WebRequestHelper) (like v2rayN/1.0 WebRequestHelper)" fail=false updated=false while IFS=':' read -r name url do ${pkgs.curl}/bin/curl --retry 3 --retry-delay 5 -fL -A "$UA" "$url" -o "$name.sub.new" if [[ $? -eq 0 ]]; then mv "$name.sub.new" "$name.sub" chmod 0600 "$name.sub" echo "Downloaded $name" updated=true else if [ -f "$name.sub.new" ]; then rm "$name.sub.new" fi fail=true echo "Failed to download $name" fi done < sublist if $fail; then echo "Failed to update some subs" if [ "$updated" = true ]; then echo "Some subs were updated, restarting dae service" systemctl restart dae.service fi exit 2 fi if [ "$updated" = true ]; then echo "All subs updated successfully, restarting dae service" systemctl restart dae.service else echo "No subs needed updating" fi ''; serviceConfig = { Type = "oneshot"; User = "root"; }; }; }

然后 dae 的配置是支持文件订阅的，这是俺的完整配置：

global { log_level: warn tproxy_port: 12345 allow_insecure: false check_interval: 30s check_tolerance: 50ms lan_interface: docker0 wan_interface: auto udp_check_dns:'dns.google.com:53,8.8.8.8,2001:4860:4860::8888' tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111' dial_mode: domain tcp_check_http_method: HEAD disable_waiting_network: true auto_config_kernel_parameter: true sniffing_timeout: 100ms tls_implementation: tls utls_imitate: chrome_auto tproxy_port_protect: true so_mark_from_dae: 0 } subscription { my_sub: 'file://my_sub.sub' } dns { upstream { googledns: 'tcp+udp://dns.google:53' alidns: 'udp://dns.alidns.com:53' } routing { request { qname(geosite:cn) -> alidns fallback: googledns } } } group { proxy { policy: min_moving_avg filter: subtag(my_sub) && name(keyword: 'Hong Kong') } ai { policy: min_moving_avg filter: subtag(my_sub) && name(keyword: 'Singapore') } } routing { pname(NetworkManager) -> direct dip(224.0.0.0/3, 'ff00::/8') -> direct dscp(4) -> direct dip(geoip:private) -> direct dip(geoip:cn) -> direct domain(geosite:cn) -> direct domain( suffix: copilot.microsoft.com, suffix: gateway-copilot.bingviz.microsoftapp.net, suffix: mobile.events.data.microsoft.com, suffix: graph.microsoft.com, suffix: analytics.adjust.com, suffix: analytics.adjust.net.in, suffix: api.revenuecat.com, suffix: t-msedge.net, suffix: cloudapp.azure.com, suffix: browser-intake-datadoghq.com, suffix: in.appcenter.ms, suffix: guzzoni.apple.com, suffix: smoot.apple.com, suffix: apple-relay.cloudflare.com, suffix: apple-relay.fastly-edge.com, suffix: cp4.cloudflare.com, suffix: apple-relay.apple.com, suffix: anthropic.com, suffix: claude.ai, suffix: cdn.usefathom.com, suffix: claudeusercontent.com ) -> ai l4proto(udp) && dport(443) -> block fallback: proxy }

上面的配置基本上足够使用，但是后续使用还是存在一些问题：

• 俺的机场是奶昔机场，最近几个月时常出问题，俺需要频繁的更新订阅，现在更新订阅的方式并不优雅。
• 不能很方便地更改节点。
• 有一段时间我更改了 geodb 的源，导致俺的分流出现了神秘问题，俺的，同样是上面的配置，但是我后来用的 Loyalsoldier/v2ray-rules-dat 把 gstatic 分在了 geosite:cn 里面，后来研究了很久才找到这个问题。
• 也许是 dns 配置的问题，也可能是分流的问题，后来一段时间所有网站都需要加载很久。

因为俺当时实在搞不明白分流的问题，俺选择的折中的方案，把 dae 作为 mihomo 的透明代理解决方案，这样同时具有双方的优点：能直接复用订阅中的分流规则，更新订阅方便，也能方便地更改节点，并且直连国内网站的性能还很高。

这是俺当时的配置：

global { wan_interface: auto log_level: info allow_insecure: false dial_mode: domain++ auto_config_kernel_parameter: true } dns { upstream { alidns: "udp://223.5.5.5:53" google: "udp://8.8.8.8:53" } routing { request { qname(geosite:cn) -> alidns fallback: google } } } node { local:'socks5://127.0.0.1:7890' } group { proxy { policy: fixed(0) } } routing { pname(NetworkManager) -> direct dip(224.0.0.0/3, 'ff00::/8') -> direct l4proto(udp) && dport(443) -> block dip(geoip:private) -> direct pname(FlClashCore) -> must_direct dip(geoip:cn) -> direct domain(geosite:cn) -> direct fallback: proxy }

这样在配置极简的情况下还能得到很多方便，只破坏了一点点纯函数式思想，不出意外俺能一直用这套方案。

但是，后续又因为奶昔机场天天炸，让俺用起来很不爽，一气之下俺选择自建小鸡（见 关于被奶昔机场逼成 MJJ 这件事）。

在这样的情况下，反而是 mihomo 开始变得麻烦了，并且俺的有些需求用 mihomo 实现比 dae 麻烦得多：

• mihomo 不能直接使用 vless 链接，要么订阅转换要么自己慢慢改配置，相比之下 dae 直接支持 vless 链接。
• mihomo 的链式代理有些复杂，至少俺研究了半天才弄明白 dialer-proxy 怎么用，相比之下 dae 可以很简单地定义代理链（见 Support for node-level proxy chain #236）。

当然上面的问题不是说 mihomo 不够好，而是对俺来说反正都要用 dae，有更省事的方案当然要用。

这是俺最后的配置：

global { wan_interface: auto lan_interface: docker0 log_level: info allow_insecure: false dial_mode: domain++ auto_config_kernel_parameter: true } dns { upstream { alidns: "tcp+udp://223.5.5.5:53" google: "udp://8.8.8.8:53" } routing { request { qname(geosite:cn) -> alidns fallback: google } } } node { # 以下为占位链接 DMIT: 'vless://dmit_vless_link' vircs: 'vless://vircs_vless_link -> vless://dmit_vless_link' } group { proxy { policy: fixed(0) filter: name(DMIT) } ai { policy: fixed(0) filter: name(vircs) } } routing { pname(NetworkManager) -> direct dip(224.0.0.0/3, 'ff00::/8') -> direct l4proto(udp) && dport(443) -> block domain(gstatic.com) -> proxy domain(geosite:google) -> proxy domain(geosite:google-gemini) -> proxy domain(geosite:category-ai-!cn) -> ai dip(geoip:private) -> direct dip(geoip:cn) -> direct domain(geosite:cn) -> direct fallback: proxy }

相比之下，俺用来过度的作用相同的 clash 配置

port: 7890 socks-port: 7891 allow-lan: false mode: rule log-level: info geodata-mode: true geo-auto-update: true geodata-loader: standard geo-update-interval: 24 geox-url: geoip: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat geosite: >- https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat mmdb: >- https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb asn: >- https://github.com/xishang0128/geoip/releases/download/latest/GeoLite2-ASN.mmdb rule-providers: category-ai-chat-!cn: type: http format: yaml behavior: domain url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geosite/category-ai-chat-!cn.yaml path: ./ruleset/category-ai-chat-!cn.yaml interval: 86400 google: type: http format: yaml behavior: ipcidr url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geoip/google.yaml path: ./ruleset/google.yaml interval: 86400 geolocation-cn: type: http format: yaml behavior: domain url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geosite/geolocation-cn.yaml path: ./ruleset/geolocation-cn.yaml interval: 86400 geolocation-!cn: type: http format: yaml behavior: domain url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geosite/geolocation-!cn.yaml path: ./ruleset/geolocation-!cn.yaml interval: 86400 private: type: http format: yaml behavior: ipcidr url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geoip/private.yaml path: ./ruleset/private.yaml interval: 86400 cn: type: http format: yaml behavior: ipcidr url: >- https://gh.sageer.me/https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geoip/cn.yaml path: ./ruleset/cn.yaml interval: 86400 dns: enable: true ipv6: true respect-rules: true enhanced-mode: fake-ip nameserver: - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query proxy-server-nameserver: - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query nameserver-policy: geosite:cn,private: - https://120.53.53.53/dns-query - https://223.5.5.5/dns-query geosite:geolocation-!cn: - https://dns.cloudflare.com/dns-query - https://dns.google/dns-query proxies: - type: 'vless' name: 'VIRCS' server: 'xxx' port: 23551 uuid: 'xxx' tls: true servername: 'www.microsoft.com' flow: 'xtls-rprx-vision' client-fingerprint: 'chrome' reality-opts: public-key: 'xxx' short-id: 'xxx' network: 'tcp' dialer-proxy: vless - name: vless type: vless server: xxx port: xxx uuid: xxx tls: true client-fingerprint: chrome servername: www.ebay.com network: tcp reality-opts: public-key: xxx tfo: false skip-cert-verify: false flow: xtls-rprx-vision proxy-groups: - type: select name: 🚀 节点选择 proxies: - VIRCS - DIRECT - REJECT - ⚡ 自动选择 - vless - name: ⚡ 自动选择 type: url-test proxies: - vless url: https://www.gstatic.com/generate_204 interval: 300 lazy: false - type: select name: 💬 AI 服务 proxies: - VIRCS - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless - type: select name: 🔍 谷歌服务 proxies: - VIRCS - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless - type: select name: 🏠 私有网络 proxies: - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless - type: select name: 🔒 国内服务 proxies: - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless - type: select name: 🌐 非中国 proxies: - VIRCS - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless - type: select name: 🐟 漏网之鱼 proxies: - 🚀 节点选择 - DIRECT - REJECT - ⚡ 自动选择 - vless rules: - RULE-SET,category-ai-chat-!cn,💬 AI 服务 - RULE-SET,google,🔍 谷歌服务 - RULE-SET,google,🔍 谷歌服务,no-resolve - RULE-SET,private,🏠 私有网络,no-resolve - RULE-SET,geolocation-cn,🔒 国内服务 - RULE-SET,cn,🔒 国内服务,no-resolve - RULE-SET,geolocation-!cn,🌐 非中国 - MATCH,🐟 漏网之鱼

目前这套配置用下来没有什么问题。

网友解答：

---

--【壹】--：

难得看到有用dae大鹅的佬友，本帖持续跟踪

---

--【贰】--：

是的，有很长时间没有更新了，但是现在感觉已经相当可用，也就是易用性这块值得优化一下了

---

--【叁】--：

btw，一个没有提到的 dae 很好用的功能是，支持通过本地主机的进程名称进行流量分流

---

--【肆】--：

dae的开发陷入停滞了，有点难受。不过目前使用上够用，已经折腾到极限了…

---

--【伍】--：

俺也是在一步一步摸索，持续学习中，但是苦于网上关于 dae 的资料实在不多。