Contents

1 前言
2 dnscrypt-proxy介绍
3 dnscrypt-proxy的安装
- 3.1 源码方式安装
- 3.2 使用docker run格式部署
4 dnscrypt-proxy.toml配置文件
5 设置dnscrypt-proxy以service方式开机启动(源码方式安装)
6 后话

1 前言

其实，我一直想在内网搭建一个稳定、无污染的 DNS 服务，专门用于解决 DNS 污染问题，供部分仅需解决DNS污染的应用使用，比如emby的tmdb插件，不能正常刮削影视信息，仅仅是因为其API地址”api.themoviedb.org”被国内DNS进行了污染而已，比如这是用国内DNS的解析结果：

而正常的解析应该是解析到AWS cloudfront的Anycast地址：

所以，这部分应用其实并不需要全局代理，需要的仅仅是一个”无污染”的DNS而已。

过去，解决DNS污染问题，我是依赖于 AC86U 路由器上 Merlin 固件内置的 Clash 插件来实现，通过它劫持 UDP 53 端口来将 DNS 请求转发到外部加密 DNS 服务。这种方式虽然也能解决DNS污染，但却存在着较大的限制：

对服务稳定性要求高：一旦 Clash 插件崩溃或重启，所有内网设备的 DNS 解析都会瞬间中断，影响面太大，属于高耦合、单点故障风险明显的方案。
受限于 AC86U 路由器：这种方案强依赖于特定型号路由器及其插件，而我现在正在逐步推动家庭数据中心中科学相关功能的”去路由器中心化”：比如将主要科学任务交由Apple TV上shadowsocket提供的HTTP代理(部分支持设置代理的应用可以直接使用)，或者配合LXC上部署的redsocks2来实现”轻量级旁路网关”功能(供不支持设置代理的应用使用，具体搭建过程参见文章：家庭数据中心系列基于 HTTP 代理的轻量旁路网关搭建：redsocks2 + iptables 实战指南)，便于后期替换硬件、集中管理：AC86U 未来不一定还会继续使用，依赖它显然不具备可持续性。

于是，我现在倾向于采用更清晰、解耦的方案，刚好我购买了10.99美金/年的位于San Jose节点的Racknerd 1核1GB内存的小鸡来做跳板机(Racknerd_低配1_879)，并可以对外开放端口(作为跳板机无所谓，但是Chicago节点那台VPS作为我的双活容灾节点，是打死不开放任何端口的)，所以计划如下：在家庭数据中心内网中另起一个 LXC 容器或 Docker 实例部署一个DNS下游节点，向内网设备提供标准的 53 端口 DNS 服务，将收到的DNS请求以加密方式发送给San Jose上的DNS上游节点；在 San Jose 节点部署一个加密的DNS上游节点，可以接收DNS下游节点发来的加密DNS请求并转发给Cloudflare、Google等众所周知的DNS服务供应商进行解析，彻底绕过国内的DNS污染。

通过这种结构，不仅实现了解耦与高可用，有需要的话还能借助DNS下游节点灵活配置按域名或按 IP 分流，国内请求走国内 DNS，国外请求走加密信道，实现国内外DNS查询分流。

不过，实现DNS上游节点和DNS下游节点的软件该如何选择呢？经过了一番考察，发现dnscrypt-proxy这个软件可以同时作为上、下游节点的软件选择。

2 dnscrypt-proxy介绍

dnscrypt-proxy 是一款功能强大且高度可定制的支持加密的本地 DNS “中继”代理工具，主要用于保护 DNS 查询过程中的隐私与完整性。它由 Frank Denis 维护，支持多种现代 DNS 加密协议，包括 DNSCrypt v2 和 DNS-over-HTTPS (DoH)，并且具备灵活的转发、过滤与策略路由能力，是构建自定义、安全 DNS 系统的核心组件之一。

相比传统明文 DNS 请求，dnscrypt-proxy 所支持的加密协议可以有效防止 ISP 或中间人监控和篡改 DNS 查询。此外，它还内置了对多个公共 DNS 提供商（如 Cloudflare、Quad9、NextDNS 等）的支持，用户可以通过配置 server_names 参数指定可信上游，或者自定义 DoH 服务器。

dnscrypt-proxy 支持在本地监听任意端口（如标准的 53 端口或自定义端口），并可将收到的 DNS 查询安全地转发至远程加密 DNS 服务端，配合如 dnsmasq 或操作系统 DNS 设定，可为整个网络提供隐私保护型的递归解析服务。它还内置了缓存机制，可提高查询速度，并支持基于域名的黑白名单过滤、EDNS client subnet 策略、匿名 DNS 中继等进阶功能。

另外，dnscrypt-proxy 的配置文件虽然结构化程度较高，但非常灵活，适合在各类环境中精细化调优。它既可以运行在高性能服务器上，作为企业级 DNS 出口节点使用，也可以轻松部署在低功耗设备（如树莓派、小型 VPS、小鸡等）上，作为轻量级家庭或个人 DNS 解决方案。

综上所述，dnscrypt-proxy 是一款兼顾性能、隐私、安全性与灵活配置能力的 DNS 加密代理工具，尤其适合追求”无污染 DNS”环境的技术用户使用，非常适合有”DNS请求加密”需求时使用，所以可以作为DNS上、下游节点的软件使用。

其实，除了 dnscrypt-proxy，AdGuard Home 同样可以满足我的需求：它不仅内置了 DoH/DoQ 等加密上游支持，还有相对完整的 DNS 策略管理能力。然而，我最终还是选择了轻量级的 dnscrypt-proxy原因主要有两点：

一来，我的需求其实非常简单，如果作为DNS上游节点软件使用时，仅仅是希望它能将DNS下游节点发来的加密的国外域名查询请求转发到一个干净、加密的 DNS 上游即可；而作为DNS下游节点软件使用时，仅仅是需要它能将内网设备对国外域名的查询请求，以加密的方式发送到DNS上游节点而已，根本不需要 AdGuard Home 那一整套广告拦截、图形界面、规则订阅等重量级功能。与其引入一堆用不到的组件，增加系统负担，还不如用最简洁、可靠的方案专注完成目标(这点我有点想当然了，最终下游节点我还是选择的AdGuard Home，原因后面讲)。

二来，San Jose 节点的小鸡本身性能较差，内存和 CPU 都比较吃紧，运行 AdGuard Home 这种需要长时间常驻的 Web 服务并不现实。而 dnscrypt-proxy 更轻量、资源占用更低，反而可以做到稳定、省心、低资源占用地运行一个长期可用的无污染 DNS上游节点。

3 dnscrypt-proxy的安装

3.1 源码方式安装

由于apt提供的dnscrypt-proxy版本实在太低(还是oldstable)：

而目前github上官方最新版是2.1.8，2025年3月27号发布：

版本相差实在是太大，关键是2.1.6版本的配置和之前版本的配置逻辑相差别比较大(最关键就是”server = true/false“这个误导性参数的移除)，所以我只推荐直接使用最新的2.1.8版本(dnscrypt-proxy github官方最新版下载)，因此只展示源码安装方式：

# 进入工作目录
cd /opt

# 下载官方 release
wget https://github.com/DNSCrypt/dnscrypt-proxy/releases/download/2.1.8/dnscrypt-proxy-linux_x86_64-2.1.8.tar.gz

# 解压
tar -xzf dnscrypt-proxy-linux_x86_64-2.1.8.tar.gz
cd linux-x86_64

# 拷贝二进制文件到系统默认路径
cp dnscrypt-proxy /usr/local/bin/

# 基于官方模板创建配置文件(可选)，后面我会直接提供最小化配置文件
mkdir -p /etc/dnscrypt-proxy
cp /opt/linux-x86_64/example-dnscrypt-proxy.toml /etc/dnscrypt-proxy/dnscrypt-proxy.toml

3.2 使用docker run格式部署

docker run --name dnscrypt-proxy -d --restart=always \
  -p 53:53/udp \
  -p 443:443/tcp \
  -p 443:443/udp
  -v /docker/dnscrypt-proxy:/config \
  -e TZ=Asia/Shanghai \
  klutchell/dnscrypt-proxy

注：需提前创建/docker/dnscrypt-proxy目录，并在其中创建dnscrypt-proxy.toml配置文件。

4 dnscrypt-proxy.toml配置文件

4.1 明确 dnscrypt-proxy 的工作模式与部署位置

在部署 dnscrypt-proxy 之前，更关键的问题不是它”到底是 Server 端还是 Client 端”，而是要明确它在你的网络架构中承担什么角色：

是运行在本地网络中、为内网设备提供 DNS 转发服务？还是部署在公网节点、为多个下游客户端提供加密中继功能？

实际上，无论部署在哪个位置，dnscrypt-proxy 都同时具备两种能力：

它会监听一个或多个端口，接收来自客户端(可能是终端，或者dnsmasq)的 DNS 请求(表现为”服务端”行为)
同时，它也会根据配置将这些请求转发给上游 DNS 服务(如 DoH、DNSCrypt 服务器等)，并接收响应(表现为”客户端”行为)

这种”前端接收请求、后端转发查询”的工作机制，决定了 dnscrypt-proxy 本质上就是一个DNS 中继代理。

因此，我们不应该机械地将其划分为 Server 或 Client(之前老版本就是这么做的，所以很容易让人混乱)，更准确的视角是：它的部署位置 + 它的服务对象是谁。

例如：

部署在本地网络中的 dnscrypt-proxy(下游节点)，通常面向内网设备提供 DNS 服务，是本地的 DNS 中继。这种情况下，它的上游可能是一个 DoH 服务器，甚至是你自己在公网节点上部署的另一个 dnscrypt-proxy(就是我现在的部署场景)。
部署在公网节点的 dnscrypt-proxy(上游节点)，则更像是一个安全 DNS 中转站，它监听公网IP地址的TCP 443 或UDP 53 端口(如果通过Cloudflare Tunnel发布DoH，则可以是任意本地端口)，对外提供 DNSCrypt 或 DoH 服务，同时将请求转发给可信的上游 DNS 服务。

4.2 常见部署场景举例

理清 dnscrypt-proxy 的中继定位之后，我们就可以根据实际需求，选择不同的部署方式和配置组合。下面是几个典型的场景，基本覆盖了常见的本地转发、远程中继、服务端提供加密协议等用法：

场景一：监听端口 + 使用加密上游 DNS（DoH/DNSCrypt 客户端，适合下游DNS节点）

listen_addresses = ['0.0.0.0:53']

doh_servers = true
dnscrypt_servers = false

此配置会在本地监听 53 端口，接收来自本地设备的 DNS 请求，并通过 DoH 向可信上游（如 Cloudflare、NextDNS或者自建的上游节点）进行加密查询。适合部署在本地网络作为一个”加密 DNS中继”，就像那句耳熟能详的广告语：”我们不生产水，我们只是大自然的搬运工”，当然，在这里需要改一下：”我不自己解析域名，我只是把其他可信上游DNS的解析结果转发给你”。

场景二：监听端口 + 使用系统 DNS（最小依赖，适合离线/调试）

listen_addresses = ['0.0.0.0:53']

doh_servers = false
dnscrypt_servers = false

不依赖任何外部加密协议，dnscrypt-proxy 会调用系统默认的 resolver（通常是 /etc/resolv.conf 中的配置）进行普通 DNS 查询。
适合用于调试、受限网络或临时脱网环境下，作为一个轻量 DNS 中继使用。

不过，这种方式并不提供任何加密能力，也容易遭遇污染劫持，不推荐用于生产环境。

场景三：监听端口 + 自身提供加密协议（DoH/DNSCrypt 服务端，适合作为自建的上游DNS节点）

# 可选，兼顾使用tailscale ip提供常规基于53端口的DNS服务
listen_addresses = ['tailscale IP:53']

# 开启 DoH 服务
[local_doh]
listen_addresses = ['你的公网IP:443']
path = '/dns-query'
cert_file = '/path/to/cert.pem'
cert_key_file = '/path/to/key.pem'

这一模式下，dnscrypt-proxy 不只是 DNS 中继，更变身为”加密 DNS 服务提供者”。例如：你可以将其部署在海外节点上，使用443 端口对外提供 DoH 服务，并使用ACME生成的证书来启用 HTTPS。内网的 dnscrypt-proxy(下游节点)可通过公网地址访问它，实现加密混淆、防干扰的 DNS 查询通道。

你甚至可以通过 Tailscale 或 VPN，让内网设备通过私网地址直接使用常规DNS查询访问它的53端口(前提是正确配置listen_address)，实现最简单的加密 DNS查询。

下游DNS节点和上游DNS节点进行加密通信的方式有2种，DoH和Dnscrypt(v2)。本文中我的配置中全是使用DoH，没有使用Dnscrypt(v2)，是因为如果要使用Dnscrypt(v2)，上游DNS节点必须监听公网IP和端口，这就导致ufw必须放开allow相应的端口访问，这和我的”全封闭”的安全指导思想(不到万不得已，打死不开放任何端口)冲突。而DoH可以配合cloudflare tunnel使用，和”全封闭”指导思想完全兼容，所以本文中只用DoH，但是这并不是说Dnscrypt不好，这点大家一定要明白。

4.3 配置范例(2.1.8版本)

4.3.1 自建上游DNS节点配置(适合海外VPS部署)

新建一个配置文件：

vim /etc/dnscrypt-proxy/dnscrypt-proxy.toml

然后将以下包含了最小可用配置的模板粘贴进去并保存：

# 主 DNS 监听地址（明文 DNS），可设为 0.0.0.0:53，但是不建议，这样就成公共DNS了，建议设置为tailscale IP
listen_addresses = ['tailscale IP:53'] 

# 指定使用哪些上游服务器的名称（来自 [sources] 列表），否则 dnscrypt-proxy 不会启用任何上游解析器
server_names = ['google', 'cloudflare'] 

# 用于自举解析上游服务器域名（如 DoH 地址）所用的传统 DNS 服务器
bootstrap_resolvers = ['1.1.1.1:53', '8.8.8.8:53']

# 网络连通性检测地址，启动前会测试是否能连通此 DNS
netprobe_address = '1.1.1.1:53'


# 本地提供 DoH 服务的设置，可作为私有 DoH 服务器使用
[local_doh]
# DoH 监听地址，需绑定在 443 端口
listen_addresses = ['公网IP:443']

# HTTP 路径，通常设为 /dns-query,但是为了防止被扫描，建议改个复杂的
path = '/dns-query'

# TLS 证书与私钥路径，建议使用有效证书（如Let's Encrypt）,如果套cloudflare，也可以使用cloudflare自签证书
cert_file = '/etc/certs/dns.tangwudi.com/dns.tangwudi.com.crt'
cert_key_file = '/etc/certs/dns.tangwudi.com/dns.tangwudi.com.key'


# 远程服务器列表来源，用于动态加载支持的上游 DNS（支持 DNSCrypt 和 DoH）
[sources]

  ### DNSCrypt 项目的主服务器列表，包含数百个公开上游服务器
  [sources.public-resolvers]
  urls = [
    'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md',
    'https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md'
  ]
  cache_file = 'public-resolvers.md'  # 本地缓存文件名
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'  # 文件签名验证公钥
  refresh_delay = 73  # 多久更新一次列表（分钟）
  prefix = ''  # 前缀可用于标识该来源中的服务器名称

  ### 匿名中继服务器列表，用于构建 Anonymized DNS 查询链
  [sources.relays]
  urls = [
    'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md',
    'https://download.dnscrypt.info/resolvers-list/v3/relays.md'
  ]
  cache_file = 'relays.md'
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  refresh_delay = 73
  prefix = ''

# 针对某些上游 DNS 服务器的兼容性修正
[broken_implementations]

# 这些服务器存在 DNS 报文分片问题，会被标记处理或避免使用
fragments_blocked = [
  'cisco', 'cisco-ipv6', 'cisco-familyshield', 'cisco-familyshield-ipv6',
  'cisco-sandbox', 'cleanbrowsing-adult', 'cleanbrowsing-adult-ipv6',
  'cleanbrowsing-family', 'cleanbrowsing-family-ipv6',
  'cleanbrowsing-security', 'cleanbrowsing-security-ipv6'
]

sources 部分不是必须的，但它是 dnscrypt-proxy 最核心的特性之一（通过远程源动态加载支持的服务器），如果你使用的是静态配置（如 [static]），那这部分可以删除。
[broken_implementations] 可选，但推荐保留，避免因为 MTU/分片问题导致解析失败，尤其是在公网部署时。

注：如果配置中未指定 server_names 或 [static]，表示 dnscrypt-proxy 会随机从 [sources] 加载的服务器中选择（默认策略是可靠性优先 + RTT 优先）。

4.3.2 下游DNS节点配置

新建一个配置文件：

vim /etc/dnscrypt-proxy/dnscrypt-proxy.toml

然后将以下包含了最小可用配置的模板粘贴进去并保存：

# 明文监听地址，使用内网IP
listen_addresses = ['192.168.x.x:53']

# 指定使用的远程上游 DNS 名称
server_names = ['sanjose-custom']  # 指向你上游节点的自定义名字

# 自举解析用的 DNS（首次解析上游节点 DoH 域名，国内的家宽就只能使用国内的域名服务器了）
bootstrap_resolvers = ['119.29.29.29:53', '223.5.5.5:53']

# 网络探测地址，可选但建议保留，避免启动失败，根据自己情况填写
netprobe_address = '119.29.29.29:53'

# 静态定义自建上游服务器（通过 DNS stamp）
[static.'sanjose-custom']
stamp = 'sdns://...'  # 你服务端生成的 stamp，含 DoH 地址及路径

4.3.3 扩展知识：stamp地址

在 DNSCrypt 协议体系中，stamp 是一种紧凑的、可分享的字符串，用来描述一个上游 DNS 服务器的连接方式与参数。它类似于一个完整的连接配置快照，包含了如下关键信息：

上游服务器支持的协议类型（如 DNSCrypt 或 DoH）
服务器的 IP 地址
（可选）主机名（用于 SNI 或 Host Header）
请求路径（DoH 特有，比如 /dns-query）
公钥（用于校验/加密）
一些标志（比如是否支持 DNSSEC、是否记录日志、是否启用过滤）

stamp 是给 下游 DNS 客户端（比如另一个 dnscrypt-proxy）使用的，用于告诉它：你该如何连接我、通过什么协议、用哪个地址、在哪个路径、用什么加密密钥。由于 stamp 是不可读的字符串（base64 编码的一种自定义变体），因此我们通常需要借助工具来生成或解码它。

为什么需要 Stamp？

最早的时候，DNSCrypt 协议(v1版本)的客户端在连接上游服务器时，需要手动填写 IP 地址、端口、公钥、路径等一堆配置项，不仅繁琐，也不统一。随着支持的功能越来越多，比如 DoH、匿名中继等，配置复杂度进一步上升。为了简化这一过程，开发者提出了 Stamp 的概念：把所有必要的信息打包成一串标准化的字符串。这个字符串既可以手动粘贴，也可以直接写进 .toml 配置文件，成为一种轻量、通用、易分发的连接描述方式。

特别是在你自建 DNS 上游服务器的场景下，没有 Stamp，就无法把自己的服务节点加到下游的 dnscrypt-proxy 配置中。所以一旦你在 VPS 或家用服务器上部署好了 DNSCrypt 或 DoH 服务，就必须为它生成对应的 stamp 才能正常使用。

如何生成stamp地址呢？很简单，直接使用dnscrypt提供的官方在线工具即可：stamp地址官方在线生成工具。

上图中的Hashes需要基于上游节点使用的crt证书用以下命令来生成：

openssl x509 -in /path/to/your.crt -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64

比如我的San Jose节点生成Hashes值：

5 设置dnscrypt-proxy以service方式开机启动(源码方式安装)

1、假设你已经完成了配置文件的修改

确保你的 dnscrypt-proxy.toml 文件已经配置完毕，并且 dnscrypt-proxy 能正常启动。测试命令如下：

/path/to/dnscrypt-proxy -config /path/to/dnscrypt-proxy.toml -check

如果测试通过，会输出如下信息：

2、**systemd 安装服务文件(如果你是源码方式安装)

创建 systemd service 文件：

vim /etc/systemd/system/dnscrypt-proxy.service

粘贴并保存以下内容：

[Unit]
Description=dnscrypt-proxy
After=network.target

[Service]
ExecStart=/usr/local/bin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Restart=on-failure
RestartSec=5
User=nobody
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

3、重新加载 systemd 配置并启用服务

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable dnscrypt-proxy
systemctl start dnscrypt-proxy

4、查看运行状态

systemctl status dnscrypt-proxy

6 后话

虽然 dnscrypt-proxy 可以同时作为上游和下游的 DNS 节点，但如果你只是想在家中部署一个为局域网设备提供 DNS 解析服务的下游节点，并且并不特别强调”极致轻量化”，那它未必是最理想的选择。

一个明显的问题在于：当你使用 dnscrypt-proxy 作为下游客户端连接自建上游节点时，你无法像大多数 DoH 客户端那样直接填写一个 HTTPS 地址(例如 https://dns.tangwudi.com/dns-query):如文章前面讲述的内容，你必须先生成一个专门的”stamp”地址，这个地址需要包括服务的公网IP、公钥、端口、路径等信息。也正因为 stamp 要包含这些字段，它要求你公网上游服务器的公网 IP(端口也需要开放访问)，这就直接限制了你不能通过 Cloudflare 的 “小橙云” 模式来隐藏节点真实 IP。

而使用如 AdGuard Home、NextDNS、或者系统层面（如 Android、iOS、macOS）的 DoH 支持作为下游 DNS节点时，只需填写标准的 HTTPS 地址即可，这种方式的优势在于：

支持 Cloudflare Proxy 隐藏上游服务器真实 IP，提升安全性与抗打能力；
无需处理繁琐的 stamp 生成、维护过程；
可灵活搭配 Cloudflare 提供的访问控制、安全检查、WAF 等服务；
对用户来说更”所见即所得”，没有复杂的格式和工具门槛。

从这些角度来看，dnscrypt-proxy 在下游场景中的最大优势之一，大概就是它非常轻量、依赖极少（无 UI、单一二进制、资源消耗极低），适合部署在资源极为有限的设备或容器中，例如某些嵌入式系统、软路由、树莓派等场景下的极简部署。但这显然并不是大多数家庭用户的主要限制条件，尤其当你已经具备了 AdGuard Home、NextDNS 等具备 Web UI 和日志管理能力的替代方案时。

所以这就有点”倒挂”的感觉：原本 dnscrypt-proxy 的 stamp 机制是为了规范配置和增强安全性，在面向公共上游服务时非常有意义，但一旦你作为使用者自己搭建了上游节点，它反而变成了一种额外负担。特别是在希望隐藏上游服务器真实 IP、通过 Cloudflare 的 CDN 套壳时，stamp 要求暴露公网 IP 的设计，会直接阻碍你套上保护壳的可能性。当然，dnscrypt-proxy 作为下游节点也并非完全无优势，它的一个独特能力是：无需依赖域名解析即可使用，仅基于 IP、公钥和端口就可以建立加密连接，这在一些特殊场景下非常宝贵——例如 GFW 大规模封锁 SNI 的时期，普通 DoH 服务可能因无法解析域名或 TLS 握手失败而中断，而 dnscrypt 协议则可以通过硬编码 IP + Stamp 的方式绕过这些限制，作为一种具备”抗封锁”特性的备用方案，这一点是其他基于 DoH 协议的下游方案所不具备的。

纠结了一番之后，最终我选择了在 San Jose 的”小鸡”上运行 dnscrypt-proxy 来搭建 DNS 上游节点（并通过Cloudflare Tunnel来发布DoH）；而在家庭数据中心内部，则选择了已经部署好的 AdGuard Home 作为下游节点，使用 DoH 地址连接上游节点，并对整个内网提供传统的 53 端口 DNS 解析服务。这样既保持了上游服务的灵活性与安全性，又简化了下游配置和管理负担，兼顾了易用性和轻量化。

在将自建的 DoH 服务(例如运行在 dnscrypt-proxy 上的 443 端口)套Cloudflare时，不同的部署方式会对回源行为产生明显影响：

如果你的上游节点 直接开放了 443 端口，且 Cloudflare 使用的是传统的 公网 IP 回源，那么无论是否启用 CDN(小橙云），DoH 服务通常都能正常工作。
而如果你的上游节点关闭443端口，选择Cloudflare Tunnel 作为回源方式，并希望将 DoH 服务暴露出去，此时就需要额外注意几个关键配置：

在 Tunnel 的服务类型中应选择 HTTPS；
务必设置”源服务器名称”（Origin Server Name），该值会作为 SNI（Server Name Indication）发送给本地服务。否则，在使用 Cloudflare 默认的严格证书校验机制（尤其开启小橙云后）时，TLS 握手可能会失败；
视具体需求，还可以设置 “HTTP Host Header”，以确保向本地服务发送的请求中包含正确的 Host 头部字段。这对于某些依赖虚拟主机配置的服务（如 Nginx 或 AdGuard Home）尤为关键。

换句话说，当你采用 Tunnel 模式暴露基于 HTTPS 的本地 DNS 服务时，“源服务器名称”就是 Cloudflare Tunnel 能否顺利完成回源的核心配置项：忘记配置它，TLS 就无从谈起。

分享这篇文章

vip券网

Windows Chrome 86.0.4240.198

1 月前
2025-5-22 3:10:53

写的很详细具体！！！赞
- tangwudi
  博主
  vip券网
  
  Macintosh Chrome 136.0.0.0
  
  1 月前
  2025-5-22 8:12:22
  
  我一般做过的操作，一些细节很快就会忘记，不写详细点，下次自己看都可能看不懂了。。
- - vip券网
    
    tangwudi
    
    Windows Chrome 86.0.4240.198
    
    1 月前
    2025-5-22 14:11:21
    
    嗯嗯，有些时候就是其中的某一步有问题导致，详细记录好些。

1 前言

2 dnscrypt-proxy介绍

3 dnscrypt-proxy的安装

3.1 源码方式安装

3.2 使用docker run格式部署

4 dnscrypt-proxy.toml配置文件

4.1 明确 dnscrypt-proxy 的工作模式与部署位置

4.2 常见部署场景举例

4.3 配置范例(2.1.8版本)

4.3.1 自建上游DNS节点配置(适合海外VPS部署)

4.3.2 下游DNS节点配置

4.3.3 扩展知识：stamp地址

5 设置dnscrypt-proxy以service方式开机启动(源码方式安装)

6 后话

评论

发送评论编辑评论

1 前言

2 dnscrypt-proxy介绍

3 dnscrypt-proxy的安装

3.1 源码方式安装

3.2 使用docker run格式部署

4 dnscrypt-proxy.toml配置文件

4.1 明确 dnscrypt-proxy 的工作模式与部署位置

4.2 常见部署场景举例

4.3 配置范例(2.1.8版本)

4.3.1 自建上游DNS节点配置(适合海外VPS部署)

4.3.2 下游DNS节点配置

4.3.3 扩展知识：stamp地址

5 设置dnscrypt-proxy以service方式开机启动(源码方式安装)

6 后话

评论

发送评论 编辑评论

推荐文章

发送评论编辑评论