【服务器篇】甲骨文云 (Oracle Cloud) 部署 AdGuard Home 实战复盘与标准操作文档

第一部分：踩坑复盘与核心认知

在本次 1核1G ARM 架构甲骨文云服务器上部署 AdGuard Home 的过程中，我们主要遭遇并解决了以下几个经典的“拦路虎”：

1. 核心认知突破：DNS 拦截的边界

• 预期误区： 试图使用 AdGuard Home 拦截迅雷 App、微信朋友圈等深度定制的广告。
• 真相复盘： DNS 拦截的原理是“域名黑洞”。对于与正常业务共享域名（骨肉相连）、内置 IP 直连、或具备严格证书校验机制的国民级 App 广告，单纯的 DNS 拦截无能为力。AdGuard Home 的主战场在于：网页去广告、系统级追踪器拦截、以及轻量级 App 的开屏/贴片广告过滤。

2. 端口占用陷阱 (53端口)

• 现象： AdGuard Home 初始化时提示 bind: address already in use。
• 原因： Ubuntu / Debian 系统自带的 systemd-resolved 服务默认占用了 53 端口。
• 解法： 必须修改系统配置，关闭自带的 DNS 监听，并重新链接 resolv.conf 文件。

3. “双层防火墙”机制 (最易被忽略的坑)

• 现象： 外部无法访问网页面板，或手机“私人 DNS”提示无法连接。
• 原因： 甲骨文云不仅在网页控制台有“安全列表（入站规则）”，其官方提供的 Ubuntu 系统内部还运行着死板的 iptables 防火墙。只开一边等于没开。
• 规则配置误区： 在配置网页控制台的安全列表时，“源端口范围”必须留空，绝对不能填具体的端口号（如 443），否则会拦截所有正常的随机端口请求。

4. Cloudflare 代理冲突 (小黄云陷阱)

• 现象： Certbot 申请证书失败，或手机配置 DoT 域名后无法连接网络。
• 原因： 域名在 Cloudflare 解析时开启了“代理”（橙色云朵）。这会隐藏甲骨文的真实 IP，且 Cloudflare 代理节点不支持转发 853 (DoT) 等特殊端口流量。
• 解法： 必须将 Cloudflare 的代理关闭，保持为灰色的“仅 DNS”状态。

5. TCP 与 UDP 的双重放行 (DoT 协议特性)

• 现象： 配置好加密后，手机私人 DNS 依然断网。
• 原因： DoT（DNS-over-TLS，853端口）在握手时需要 TCP 协议，在后续高频查询时往往依赖 UDP 协议。防火墙漏开 UDP 会导致连接彻底失败。

第二部分：AdGuard Home 标准部署与配置手册

适用环境： Oracle Cloud (Ubuntu ARM / AMD 实例) + 流量卡环境 (安卓私人DNS)

步骤一：云服务商网络放行 & 域名解析

1. 域名解析： 在 Cloudflare (或其他域名商) 添加 A 记录，指向甲骨文云公网 IP。⚠️ 必须关闭代理（保持灰色云朵/仅 DNS）。

2. 配置甲骨文安全列表： 登录甲骨文云网页后台，进入实例的“虚拟云网络” -> “安全列表”，添加入站规则：

   • 源 CIDR： 0.0.0.0/0
   • 源端口范围： （留空）

   • 目标端口与协议分别添加以下五条：

     • TCP 53 (常规 DNS)
     • UDP 53 (常规 DNS)
     • TCP 80 (Certbot 证书申请)
     • TCP 443 (HTTPS 后台)
     • TCP 853 (手机私人 DNS/DoT)
     • UDP 853 (手机私人 DNS/DoT)
     • TCP 3000 (初始化面板)

步骤二：服务器系统内部环境准备

赞助-蜜雪冰城 赞助-瑞幸咖啡 赞助-星巴克

微信支付

HK支付宝

支付宝

微信支付

HK支付宝

支付宝

微信支付

HK支付宝

支付宝