兄弟，我懂你现在的糟心——明明把系统DNS指向了OPNsense路由器，也关了Firefox的DoH，居然还有程序偷偷连Cloudflare的1.1.1.3 DoH。结合你的原生Ubuntu场景，我给你几个实打实的排查方向，应该能揪出根源：

• 先精准定位发起连接的进程
  这是最直接的突破口，先搞清楚到底是谁在搞事情：

  • 用ss命令实时查看连接到1.1.1.3的进程信息：

    sudo ss -tup dst 1.1.1.3
    

    它会显示目标地址为1.1.1.3的TCP/UDP连接，以及对应的进程名称、PID，一眼就能锁定嫌疑对象。
  • 如果没抓到实时连接，就用tcpdump蹲守流量，等下次连接触发时抓包：

    sudo tcpdump host 1.1.1.3
    

    抓到包后，再结合lsof -i @1.1.1.3就能对应到具体进程。

• 检查systemd-resolved的独立DoH配置
  现在Ubuntu默认用systemd-resolved管DNS，你改了/etc/systemd/system.conf但可能没覆盖它的单独设置：

  • 打开/etc/systemd/resolved.conf，检查DNS、DNSOverTLS这两项，看有没有被偷偷设成Cloudflare的地址（比如1.1.1.3）
  • 用resolvectl status查看当前生效的DNS配置，确认有没有异常的DoH服务器。如果发现问题，改完配置后重启服务：sudo systemctl restart systemd-resolved

• 排查软件更新相关的后台服务
  虽然你暂时解决了更新被拦的问题，但apt或者snap这类后台服务可能藏着硬编码的DoH设置：

  • 扫一遍/etc/apt/apt.conf.d/下的所有文件，看看有没有和DNS、代理相关的自定义配置，比如Acquire::http::Proxy这类
  • 如果你的系统用snap，检查它的独立DNS设置：

    snap get system proxy
    

• 排查其他系统后台进程
  一些系统级的同步、监控服务也可能偷偷用DoH：

  • 要是之前用ss拿到了PID，直接用ps aux | grep <PID>看进程的详细信息，比如它的配置文件路径
  • 用systemctl list-units --type=service列出所有运行的系统服务，重点排查和网络、DNS相关的，比如NetworkManager有没有被配置成自动用DoH

等你定位到具体进程后，直接修改它的DNS/DoH设置或者禁用相关功能就搞定了。

备注：内容来源于stack exchange，提问作者user220182