MoreRSS

site iconDolingou 修改

博客 区块链
技术爱好者，加密货币关注者。对Linux、Neovim、OpenWRT等技术有研究，
RSS: https://www.dolingou.com/rss/feed.xml
请复制 RSS 到你的阅读器，或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Dolingou 的 RSS 预览

EasyTier内网穿透及组网教程

2025-03-30 08:00:00

😀
最近出门的次数变得越来越多，在外出的时间，家里的网络维护以及内网数据资料的获取成为了一个新的难题。之前我也有尝试过使用Tailscale以及Zerotier等方式进行内网穿透回家，但是由于Zerotier和Tailscale的中心服务器都是在国外，同时父母家那边的网络由于是社区宽带，已经不知道NAT了多少次，所以远程管理的效果还差也很折磨。这次发现了一个新的内网穿透软件：EasyTier，可以在一定程度上缓解上述提到的问题。这篇文章进行一些EasyTier的配置讲解
notion image

📝 EasyTier 介绍

EasyTier是一个去中心化的VPN组网方案，由Rust和Tokio驱动。相对于Zerotier、Tailscale的区别也在于去中心化这个特点，客户端即服务端，处于不同网络环境下的客户端在组网的同时，也是服务端的一部分，提供基于RPC的中继能力。相比于Zerotier于Tailscale的中心化组网方案，EasyTier在具有多客户端的情况下，借助P2P异地组网，相比传统的中心化组网方案，成功率更高，可实现更好的内网穿透效果，更有效的利用家宽的上下行带宽。

EasyTier 特点

以下部分内容摘选自EasyTier的Github项目介绍页面
  • 去中心化：无需依赖中心化服务，节点平等且独立。
  • 安全：支持利用 WireGuard 加密通信，也支持 AES-GCM 加密保护中转流量。
  • 高性能：全链路零拷贝，性能与主流组网软件相当。
  • 跨平台：支持 MacOS/Linux/Windows/Android，未来将支持 IOS。可执行文件静态链接，部署简单。
  • 无公网 IP 组网：支持利用共享的公网节点组网，
  • NAT 穿透：支持基于 UDP 的 NAT 穿透，即使在复杂的网络环境下也能建立稳定的连接。(据说在NAT4-NAT4网络下也可能打洞成功)
  • 子网代理（点对网）：节点可以将可访问的网段作为代理暴露给 VPN 子网，允许其他节点通过该节点访问这些子网。
  • 智能路由：根据流量智能选择链路，减少延迟，提高吞吐量。
  • TCP 支持：在 UDP 受限的情况下，通过并发 TCP 链接提供可靠的数据传输，优化性能。
  • 高可用性：支持多路径和在检测到高丢包率或网络错误时切换到健康路径。
  • IPV6 支持：支持利用 IPV6 组网。
  • 多协议类型: 支持使用 WebSocket、QUIC 等协议进行节点间通信。
  • Web 管理界面：支持通过 Web 界面管理节点。

个人使用感受

目前我的网络环境为电信宽带，具有公网IPv4 + 公网IPv6，手机使用联通5G，正常情况下可以实现在建立连接之后3-5秒内实现P2P的内网穿透，不再借助中继服务器进行数据传输，同城延迟在50ms左右，如果是相同运营商的宽带，理论上同城延迟会更低。
同时，在CoalCloud（碳云）的VPS，在启用EasyTier作为节点后，与家里的Debian旁路网关和手机均可即时建立P2P连接，无需EasyTier提供公共服务器进行数据传输。

📝 EasyTier 安装方法

目前EasyTier提供了多种安装方式，以适应不同的系统平台，同时提供多种第三方工具，可用于对EasyTier节点进行管理，例如EasyTier Game ( Windows )、EasyTier Manager ( Windows )、luci-app-easytier ( OpenWrt )等。
我个人目前将EasyTier部署在家庭网络内的旁路网关上，并使用了点对网的子网代理，整体使用官方所提供的一键安装脚本。同时为了进行中继通信和在与NAT44网络内设备建立连接情况下，我通过Docker Compose方式将EasyTier也部署在了CoalCloud的VPS上。在旁路网关部署未使用Docker Compose的原因在于我需要使用点对网的子网代理，即通过旁路网关作为跳板，实现对局域网内其他设备的访问与管理，如果通过Docker实现，可能会增加网络的复杂性，所以只使用了脚本安装。
EasyTier不区分服务端与客户端，所以的节点所使用的程序都是一样的，所以在了解以下基于Debian的节点安装及配置之后，可以举一反三，在其他设备进行配置。如果使用OpenWRT，可以尝试在软件仓库中搜索，大部分软件仓库均已收录EasyTier。

EasyTier 一键安装脚本

首先确保你的系统以及安装了wget和unzip 这两个必须的依赖，如果没有安装可通过如下命令安装（Debian、Ubuntu等使用apt进行软件包管理的系统）：
然后通过如下命令进行EasyTier的脚本一键安装：
默认脚本下载位置位于/tmp 临时文件夹下，安装完成后可进行删除。

EasyTier 基础配置

EasyTier安装后，默认的配置文件位于/opt/easytier/config/default.conf ，下面列出我的配置文件宫参考，你也可以通过config_generator生成自己的配置文件：
各项参数意义如下：
instance_name: 实例名称
instance_id : 实例的uuid，可以使用config_generator生成
ipv4 ：当前设备的虚拟局域网IPv4地址，如果你需要手动为设备指定虚拟局域网的IPv4地址，则需要此项，否则可删除。
dhcp : 如果你需要手动为当前设备指定虚拟局域网IPv4地址，并已经包含了ipv4的参数项，则此项填写为false，如果你希望自动为当前设备分配虚拟局域网IPv4地址，则填写true.
listeners : 一般情况下无需改动。如果你希望使用不同的端口，则自行修改端口并对端口进行防火墙放行。
rpc_portal ： 默认端口为0，在官方文档中表示默认会尝试使用15888，但实际并没有使用，EasyTier启动后无法通过easytier-cli进行数据获取，报错信息如下所示。所以建议修改监听端口为15888
network_name：虚拟局域网的名称。EasyTier是通过network_name和network_secret进行网络的识别与连接确认，所以需要客户端的network_name和network_secret 完全一致。建议使用复杂一些的网络名称
network_secret ：虚拟局域网的网络密钥。
uri ：节点地址，可使用官方提供的节点（tcp://public.easytier.cn:11010），如果你自建了VPS节点，也可填写tcp://IP:PORT ，默认端口为11010。也可以查看EasyTier 公共服务器列表，选择最适合自己网络环境的公共服务器节点。
enable_kcp_proxy ：是否开启KCP代理，将TCP流量转换为KCP流量，提升传输速度与降低延迟。建议开启。
latency_first ： 延迟优先，建议开启。
enable_exit_node：是否设置当前节点为出口节点。目前建议关闭，由于EasyTier无法进行DNS劫持，所以暂时无法像Tailscale或者Zerotier使用出口节点进行翻墙等科学上网操作。
dev_name : 设置tun网卡名称，如果你的设备具有多个程序在使用tun设备，那么建议修改一下名称，避免产生冲突。
proxy_forward_by_system ： 使用系统转发替代EasyTier内置转发。相对来说性能会有所提高，但是你需要对防火墙有一定的了解，或者你的节点部署在局域网环境内，没有开启防火墙。 bind_device ： 没有在配置项中列出的部分。即是否绑定物理设备，如果你的机器使用了很多的虚拟网络设备，建议删除该项，使其绑定物理网卡，避免产生无法连接问题 use_smoltcp ： 是否使用用户态协议栈，避免操作系统防火墙导致的无法子网代理 / KCP 代理。个人目前是删除了该项，因为暂时没有发现因防火墙导致的无法子网代理问题，同时在开启用户态时，性能损耗较为严重。 relay_all_peer_rpc ： 转发所有对等节点的RPC数据包，帮助非当前虚拟局域网的其他节点建立连接。为了安全以及流量考虑，建议关闭或删除。 enable_encryption ： 是否禁用加密。false为开启加密，true为禁用加密，默认为false。

防火墙放行EasyTier端口

EasyTier默认监听端口为11010 ，如果你使用系统防火墙，需要对端口进行放行。同时如果部署在家庭网络内，需要在路由器的防火墙对11010端口也需要进行放行操作（Forward）。

EasyTier 运行命令

启动EasyTier

其中@default即使用defalt.conf配置文件，以下皆同。控制命令基于Systemd。

重启EasyTier

停止EasyTier

查看EasyTier运行状态

EasyTier-CLI命令

查看EasyTier已连接的节点

返回结果类似于如下，即已经建立连接的节点和目前的基本情况，包括是否使用P2P、延迟、丢包、NAT类型等：

查看EasyTier当前节点信息

返回结果大概与下面的信息相似，包括当前的虚拟局域网IPv4地址，子网代理范围，节点ID、公网IPv4地址、公网IPv6地址等。

EasyTier 子网代理

子网代理即点对网的组网方案，可通过一台跳板机进行局域网内其他设备的访问，且无需为局域网内其他设备配置EasyTier。例如你的EasyTier部署在主路由上，但在外面时候想访问家里的NAS，那么就需要点对网的组网方案。
EasyTier的点对网组网非常简单，在配置文件中增加如下部分：
cidr即你需要实现点对网组网的网段，例如我家里的局域网网段为10.0.0.0/24，那么即填写这个网段，如果你的是192.168.1.1类似的局域网地址，那么对应的cidr为192.168.1.0/24 。

🤗 总结归纳

目前在测试过程中还存在如下问题或未测试项：
  • 出口节点目前不能代理DNS流量，即EasyTier无法对设备的DNS进行劫持，所以无法实现通过节点进行科学上网。目前也不支持Magic DNS功能。
  • 完全NAT44且不具有IPv6公网地址情况下的内网穿透表现还未进行测试
  • WireGuard目前还未进行测试，因为我基本上不用WireGuard。这几天看看抽空研究一下。

📎 参考文章

 
💡
有关Easytier安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~ 版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处！
 

使用Caddy反向代理加速NotionNext博客图片访问

2025-01-02 08:00:00

📌
NotionNext默认使用的是Notion图床。Notion在国内没有服务器，所以通过Notion.so域名请求的图片资源文件在国内的访问速度不是很好，我们可以通过使用Caddy反向代理的方式加快Notion.so的图片访问，降低加载图片所需时间，从而提高使用NotionNext的博客在国内（大陆地区）的访问速度与用户体验。
我这个使用NotionNext，部署在Vercel上的博客页面加载时间太长的问题，也是由于昨天突然博客的国内用户的访问量增加，我在Cloudlfare Web Analytics里面进行日常数据查看时发现的，涉及到的文章页面主要是《小米15手机（澎湃OS2）：如何关闭推荐广告 | Deep Router》这篇文章，原因在于这篇文章我放了很多的手机截屏图片，这些图片需要进行加载，即使我已经使用了图片的延迟加载功能，但是依旧会因为首屏需要加载3-4张图片，而造成整体页面的加载时间过长，影响用户体验。因为Notion在国内没有服务器，访问速度不算很好，所以大部分图片的LCP（Largest Contentful Paint）延迟都在5秒左右，FCP也因为我未使用webp格式的图片造成访问延迟上升。在一篇包含很多张图片的文章里，整体的加载速度更堪称灾难级，可能需要30秒以上才能完成首屏加载，这一点在移动端设备上，因为性能差异进一步被放大。为了优化博客国内的访问体验，所以我尝试寻找解决方案，让NotionNext的图片加载不再那么灾难。在《Nginx设置Notion反代加速NotionNext图片资源访问》这篇文章中（原文章似乎被作者删除，目前处于404状态），文章作者提到可以通过使用Nginx反向代理（反代）方式进行解决，通过Nginx将用户对图片素材的访问请求反向代理至notion.so，这样只要部署Nginx的机器在国内的访问速度够快，那么托管的Notion上的图片资源也能够很快的进行加载，降低LCP延迟。但是我没有使用Nginx作为Web服务器，而是使用的Caddy这个更轻量化的解决方案，所以就在这篇文章的基础上，提供一份基于Caddy的反向代理解决方案。
在开始之前，我们先查看一下目前Notion.so在国内的访问情况，大部分浅绿，平均加载时间在3s左右，且在部分地区无法直接进行访问：
notion image

📝 Caddy反向代理配置前提

你需要一台云服务器，境内境外均可，我所使用的小鸡（云服务器）是在香港，购自CoalCloud（碳云），国内访问速度在ITDOG上查询还不错。平常只作为RSS推送服务和Docker加速镜像使用。如果不使用Cloudflare的话，需要自行在云服务器为用于反向代理的域名申请证书，例如使用letsencrypt或者acme，但是如果你也和我一样使用Caddy的话，那么Caddy会自动帮你通过acme申请好所配置的域名的证书。
也有一些解决方案是通过Cloudflare Worker实现，我没有使用Cloudflare Worker进行反向代理的原因是担心会被认为在滥用，从而导致Cloudflare账号被封禁（Ban）或限制服务。

📝 什么是Caddy

Caddy是一个开源的Web服务器和反向代理工具，专注于简化HTTP服务器的配置流程和提升安全性。它以自动化HTTPS部署为核心特性，无需手动操作即可为站点申请并更新SSL/TLS证书。支持HTTP/3、静态文件托管、负载均衡、反向代理等功能，通过简洁的配置文件（或直接通过 API）即可快速部署HTTP服务。Caddy凭借原生Go语言编写的高效性和跨平台兼容性，常被用于轻量化场景，适合Web开发者和运维人员快速构建安全的网络服务，作为Nginx的替代服务。
Caddy的最新版本是Caddy2，目前主流版本也是Caddy2。需要注意的是，Caddy和Caddy2的配置文件语法并不完全一样，当你无法确认自己编写的配置文件是否符合Caddy2语法时，可通过以下命令进行测试：

📝 安装Caddy

Caddy的安装很简单，由于不使用其他第三方插件，所以可以直接通过系统的包管理器进行安装，例如我使用的是Debian系统：
如果你需要使用缓存，或者使用其他Caddy的插件，你也可以通过Download Caddy增加所需插件，例如缓存插件darkweak/souin/plugins/caddy，并进行二进制可执行文件的下载。Caddy的插件是通过Go的编译时插件系统实现，即需要在Caddy编译时绑定并集成插件，与Nginx和Apache有所区别。增加插件后的Caddy可支持特定语法。目前虽然Caddy也支持通过caddy install 命令增加插件，但还处于实验性阶段，可能存在潜在的稳定性风险。
在Bash中，可通过以下命令查看Caddy已安装的插件：

📝 修改Caddy配置文件

这里我所使用的域名是notion.dolingou.com ,即通过notion.dolingou.com域名替代notion.so域名从而实现反向代理加载位于Notion上的图片。安装完Caddy之后，默认的Caddy配置文件位于/etc/caddy/Caddyfile ，你可以使用你喜欢的编辑器进行编辑，例如我使用的是Neovim ，在配置文件中添加如下内容，通过{}进行片段的包裹：

Caddy2配置要点

配置要点部分对上述配置文件进行分片段讲解。

压缩模式

涉及代码段：
采用gzip压缩，降低带宽利用。

拒绝所有非来自博客域名请求

涉及代码段：
这部分代码主要是定义非来自博客的域名请求host，避免这个反向代理被恶意使用，造成反向代理服务器的负载过高出现问题，或者盗刷大量流量。所有非博客域名的请求均会返回403错误。你可以将*.dolingou.com 替换为你的域名。

处理Caddy反向代理域名根目录请求

根目录请求处理涉及代码段：
这部分代码主要用于定义域名所绑定的根目录位置，以及当用户直接访问根目录及根目录下/image时，返回200 请求，并设置响应头的Content-Type为text/plain ；一方面为特定路径提供简单的占位符响应，另一方面可以快速测试服务器的响应，便于Debug。

Caddy反向代理转发配置

反向代理转发配置部分涉及代码段：
这段代码用于定义NotionNext图片的请求路径，将匹配特定路径的请求代理转发到目标服务器https://www.notion.so，并在转发过程中设置一些请求头、Host、Referer、User-Agent和SSL/TLS配置。
具体如下：
  1. 定义匹配器 @imagePath：
    • @imagePath 是一个匹配器（matcher），用于匹配特定的请求路径。
    • path_regexp image ^/image.*$：使用正则表达式匹配路径。
      • ^/image.*$：匹配以 /image 开头的所有路径，例如 /image、/image/123、/image/test.jpg 等。
    • 这个匹配器会捕获所有路径符合正则表达式 ^/image.*$ 的请求。
    1. 反向代理配置：
      • reverse_proxy 是一个指令，用于将请求代理转发到指定的后端服务器。在Caddy 1版本中，反向代理是proxy
      • @imagePath：指定匹配器，表示仅对匹配 @imagePath 的请求生效。
      • https://www.notion.so：目标服务器的地址，所有匹配的请求都会被转发到这里。根据NotionNext的默认配置文件NEXT_PUBLIC_NOTION_HOST 的默认值提示，填写notion.so域名。
      1. 设置请求头：
        • header_up 是一个指令，用于设置转发到后端服务器的请求头。
        • Host www.notion.so：将 Host 头设置为 www.notion.so，确保后端服务器知道请求的目标主机。
        • Referer https://www.notion.so：将 Referer 头设置为 https://www.notion.so，模拟请求来源。
        • User-Agent {http.request.header.User-Agent}：将 User-Agent 头设置为客户端原始请求的 User-Agent，确保后端服务器能够识别客户端类型。
        • X-Real-IP {http.request.remote.host}：将 X-Real-IP 头设置为客户端的真实IP地址，用于后端服务器记录或处理。
        • Accept-Encoding ""：清空 Accept-Encoding 头，防止后端服务器返回压缩内容（如果需要）。
        • Accept-Language {http.request.header.Accept-Language}：将 Accept-Language 头设置为客户端原始请求的 Accept-Language，确保后端服务器返回正确的语言内容。
        • X-Cache {http.reverse_proxy.header.X-Cache-Status}：将 X-Cache 头设置为反向代理的缓存状态（如果有）。
        1. SSL/TLS配置：
          • transport http：定义HTTP传输配置。
          • tls：启用TLS（HTTPS）加密，确保与后端服务器的通信是安全的。
          • tls_server_name www.notion.so：设置TLS的服务器名称为www.notion.so，用于SNI（Server Name Indication）验证。
          完成以上配置后，直接访问反代域名，这时候浏览器应该会显示一个200 OK！ ，即表示配置成功。
          1. Caddy缓存配置：
          我没有像上面Nginx样例中一样为反向代理添加缓存。原因在于目前Caddy2自身没有提供缓存功能，需要通过插件实现。而插件在命中率和缓存污染等方面的实现情况并不是很好。我的博客本身流量也不是很大，而且又有Cloudflare的CDN作为缓存，所以也就没有继续研究Caddy的这部分缓存功能。
          1. 重启Caddy
          在完成上述Caddyfile配置文件修改后，需要对Caddy进行重启：

          📝 配置Vercel环境变量

          完成以上在云服务器的Caddy配置后，在Vercel中的NotionNext项目下添加环境变量NEXT_PUBLIC_NOTION_HOST，用于替换默认的Notion Host变量（https://notion.so）。
          Vercel环境变量配置的位置位于Settings → Environment Variables 中，在Key中输入变量名称，Value中输入变量值，点击Save即可新增环境变量：
          注意需要携带https，否则该Notion Host无法正常使用，Vercel无法识别是否为https链接。添加上述环境变量完成后，需要在Vercel中对NotionNext进行重新部署（Redeploy）即可生效。
          这时候打开博客的图片，查看图片地址，应该类似于https://notion.dolingou.pro/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F6d3fda40-6b03-4bf3-842b-4c9bb68a90f1%2F5a7f71fc-218f-4ac0-b76f-e471232cd7647%2Fandroid-chrome-512x512-min.webp?table=collection&id=f87dcb58-ba2a-40bb-a156-53d7877975e9&t=f87dcb58-ba2a-40bb-a156-53d7877975e9&width=800&cache=v2" 这种。如果直接访问这个地址，会通过302重定向的方式，经由s3.us-west-2.amazonaws.com ，最终到https://img.notionusercontent.com/s3/prod-files-secure%2F6d3fda40-6b03-4bf3-842b-4c9bb68a90f1%2F5a7f71fc-218f-4ac0-b76f-e47602cd7647%2Fandroid-chrome-512x512-min.webp/size/w=800?exp=1741086188&sig=klZmCOx0XSjO_rQwnGGeMEyR_Kuz1dct7Y5cyf3Fdv4 。

          🤗 Caddy反向代理配置总结归纳

          因为我最终还是将反向代理域名使用Cloudflare CDN服务，也就是开启小黄云，所以为反向代理域名配置了SaaS回源使用Cloudflare域名优选（没错，CNAME到了Linux.do），优化国内的访问速度。同时由Cloudflare提供缓存，故未在反向代理服务器的Caddy配置中添加缓存配置。目前的国内访问情况如下，相比使用默认的Notion.so ，在全国范围内速度提升了不少，响应延迟基本都控制在1.5s ~ 2s左右，同时在访问可达性上来说，全国范围应该都可以正常访问。
          notion image
          由于最近更换了博客域名，所以图床的反向代理链接也进行了更新，现在是notion.deeprouter.org，在上面教程中的域名，也都已经替换为这个新的域名。

          📎 参考文章

          💡
          有关Caddy安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~

          国内外DNS服务器推荐列表

          2024-09-05 08:00:00

          😀
          之前介绍了不少关于MosDNS、AdGuard Home和OpenClash的内容，里面绕不开的一个部分就是：用来解析国外域名，获取无污染解析结果的DNS服务器应该选择哪家，或者说有哪些无污染的公共DNS服务器可以选择。今天这篇文章，就对我使用过的DNS服务器进行一个整理，并进行无污染DNS服务器的推荐。

          📝 个人对DNS服务器选择的看法

          DNS服务器的主要作用是将域名解析转换为IP地址，同时支持负载均衡、高可用性、反向解析、缓存加速等功能。DNS是互联网的基础设施之一，几乎所有的网络通信都依赖于DNS服务。所以选择一个稳定、高速且无污染的DNS的重要性不言而喻。在使用DNS分流的情况下，对国内域名与国外域名分别配置DNS可以有效提升解析速度与准确性，例如我在使用的MosDNS和AdGuard Home。

          📝 国内DNS服务器

          国内的公共DNS服务选择不多，我认为国内DNS只有三个选择，阿里云公共DNS（阿里巴巴）、DNSPod（腾讯）以及各省市运营商下发的DNS。阿里云公共DNS和DNSPod均支持ECS（edns-client-subnet）协议，在一定程度上可以缓解整体解析速度不如运营商DNS的情况。其他例如114、360、百度等等，均有前科，不太推荐选择。
          同时在国内DNS的选择及使用上，我个人更推荐使用DOH、DOT方式，避免DNS泄露给运营商，从而产生DNS劫持。在部分省份，运营商DNS劫持会将目标网站的解析结果返回为反诈页面，例如被运营商DNS劫持到www.js96110.com.cn
          名称
          标准DNS地址
          DOH地址
          DOT地址
          是否支持H3
          ECS
          DNSPod
          119.29.29.29 / 182.254.116.116
          https://doh.pub/dns-query
          dot.pub
          否
          支持
          AliDNS
          223.5.5.5 / 223.6.6.6
          https://dns.alidns.com/dns-query
          dns.alidns.com
          是
          支持

          📝 国外DNS服务器

          我个人一般会用Google DNS、NextDNS、以及AdGuard DNS作为主要无污染DNS使用。NextDNS的免费额度足够家庭使用，当免费额度用完就切换到AdGuard DNS。在Google DNS存在国内访问问题的时候，会选择Quad9或者OpenDNS。Cloudflare DNS在我这里的稳定性和速度并不好，所以很少选择。大多数的国外公共DNS均可以返回无污染的DNS解析结果，这些公共DNS服务基本都支持DNSSEC。
          在衡量与选择国外公共DNS服务时，延迟与丢包一般是我首先考虑的因素，其次就是DOH（DNS over HTTPS）和DOT（DNS over TLS）的支持，如果能够支持H3（http3）或者tls pipeline的话，那么一般就会是首选的DNS服务。其他次级考虑的因素还包括是否支持ECS，如果可以支持ECS，我会选择代理出口位置附近的IP。通过MosDNS的ECS功能，可以自定义ECS地址，使解析的CDN结果更靠近所配置的IP地址，从而提高解析结果的访问速度，例如我喜欢配置国外的ECS地址为代理的出口地址，这样通过代理访问时，可以获得最佳速度及可用性。
          同时在使用DOT或DOH使，可使用dial_addr替代域名，可免去每次建立连接时需要Bootstrap DNS先解析DNS服务器域名。dial_addr一般为标准DNS的IPv4和IPv6地址。
          由于一些公共DNS使用DNSCRYPT，需要使用DNS服务器公钥，存在局限性，所以暂时未列入表单内，也不作为DNS选择与衡量的指标。
          同时大部分公共解析服务均为IPv4和IPv6双栈，即使用IPv4的DNS公共解析服务也可以解析IPv6地址，所以列表内不再进行IPv4和IPv6的区分。
          在设备支持的情况下，非常建议选用支持DoH与DoT的DNS服务器。

          推荐使用的DNS服务器

          DNS服务名称
          标准DNS地址
          DoH地址
          DoT地址
          是否支持H3
          ECS
          Google DNS
          8.8.8.8 / 8.8.4.4
          https://dns.google/dns-query
          dns.google
          是
          支持
          Cloudflare
          1.1.1.1 / 1.0.0.1
          https://cloudflare-dns.com/dns-query
          1dot1dot1dot1.cloudflare-dns.com
          是
          支持
          Quad9
          9.9.9.9 / 149.112.112.112
          https://dns.quad9.net/dns-query
          dns.quad9.net
          否
          支持
          AdGuard Public DNS
          94.140.14.14 / 94.140.15.15
          https://dns.adguard.com/dns-query
          dns.adguard.com
          否
          支持
          NextDNS
          45.90.28.0 / 45.90.30.0
          https://dns.nextdns.io
          45.90.28.0 / 45.90.30.0
          是
          支持
          OpenDNS
          208.67.222.222 / 208.67.220.220
          https://doh.opendns.com/dns-query
          208.67.222.222 / 208.67.220.220
          否
          支持
          Yandex DNS
          77.88.8.8 / 77.88.8.1
          https://doh.yandex.net/dns-query
          dns.yandex.net
          否
          不支持
          CleanBrowsing
          185.228.168.9 / 185.228.169.9
          https://doh.cleanbrowsing.org/dns-query
          security-filter-dns.cleanbrowsing.org
          否
          不支持
          jp.tiar.app
          172.104.93.80
          https://jp.tiarap.org/dns-query
          jp.tiar.app
          否
          不支持
          Comodo Secure DNS
          8.26.56.26
          https://doh.comodo.com/dns-query
          dns.comodo.com
          否
          不支持
          DNS.WATCH
          84.200.69.80
          https://dns.watch/dns-query
          ㅤ
          否
          不支持
          Blahdns（新加坡）
          46.250.226.242 2407:3640:2205:1668::1
          https://doh-sg.blahdns.com/dns-query
          dot-sg.blahdns.com
          是
          不支持
          CleanBrowsing
          185.228.168.9 185.228.169.9
          https://doh.cleanbrowsing.org/doh/security-filter/
          security-filter-dns.cleanbrowsing.org
          否
          不支持
          Block malware
          76.76.2.1
          https://freedns.controld.com/p1
          tls://p1.freedns.controld.com
          否
          不支持
          DeCloudUs 
          78.47.212.211：9443
          https://dns.decloudus.com/dns-query
          tls://dns.decloudus.com
          否
          不支持
          Mullvad（新加坡）
          -
          https://dns.mullvad.net/dns-query
          tls://dns.mullvad.net
          否
          不支持

          仅作测试使用的DNS服务器

          以下DNS服务器是仅作测试使用的DNS服务器，不建议作为日常主力使用DNS解析服务，推荐仅在测试时进行使用，或作为落地区域的DNS使用。这些DNS服务大多不提供DOH或DOT选项，且在直连情况下存在延迟较高、丢包较多等不稳定因素。
          DNS服务名称
          标准DNS地址
          DoH地址
          DoT地址
          是否支持H3
          ECS
          HKBN DNS
          203.80.96.10 / 203.80.96.9
          不支持
          不支持
          否
          不支持
          NTT Communications DNS
          61.213.169.170 / 61.213.169.171
          不支持
          不支持
          否
          不支持
          NEC BIGLOBE DNS
          202.225.96.66 / 202.225.96.68
          不支持
          不支持
          否
          不支持
          Yahoo Japan DNS
          182.22.70.1 / 182.22.70.2
          不支持
          不支持
          否
          不支持
          DNS.SB
          45.11.45.11
          https://doh.dns.sb/dns-query
          dot.sb
          否
          不支持
          腾讯国际
          162.14.21.178/ 162.14.21.56
          不支持，可通过腾讯云套娃DOH
          不支持，可通过腾讯云套娃DOT
          否
          不支持
          Microsoft DNS / Level 3 Communications
          4.2.2.2 / 4.2.2.1
          不支持
          不支持
          否
          不支持
          HiNet/中華電信
          168.95.1.1 / 168.95.192.1
          不支持
          不支持
          否
          不支持
          TWNIC Quad101 Public DNS
          101.101.101.101 / 101.102.103.104
          不支持
          不支持
          否
          不支持

          DNS延迟测试脚本

          这个Python脚本需要ping3依赖，复制以上代码并保存为*.py文件，通过命令行运行。可替换IP地址为自己想要进行测速的DNS的IP地址，每个DNS的IP地址Ping次数默认为4 。脚本的注释算是清晰，可根据自己需要在脚本中修改。

          非公共DNS服务（增强型DNS服务）

          这里的非公共DNS是指提供具有用户唯一标识的DNS服务，允许用户自定义DNS过滤与隐私保护，提供访问控制，提供查询日志，提供部分路由优化等。相较于免费的公共DNS服务，这种DNS服务在部分情况下访问速度可能会更好一些。基础的DOH、DOT、DNSSEC、ECS基本都支持。
          • XNS.One提供非公共DNS使用，属于付费服务，需要邀请码，可以在他们的Telegram频道蹲一下。付费不支持支付宝与微信，只能信用卡付款。
          • NextDNS，我目前主要使用的DNS服务，免费版每个月提供30万次查询，基本够日常使用。可定制拦截列表。
          • AdGuard DNS，与NextDNS类似，免费版每个月提供30万次查询，允许配置5个接入点，2个服务器，支持配置100条自定义规则。

          📝 其他关于DNS的参考信息

          enable_pipeline: TCP/DoT使用RFC 7766新的query pipelining连接复用模式。
          • 启用后可大幅提高连接利用率，减少建立连接/握手的次数，进而降低响应延时。
          • 并非所有DNS服务器都支持。必须确定DNS服务器支持后再启用该选项。
          • Tips: 已知Google和Cloudflare的TCP/DoT是支持该模式的。知名的公共DNS服务商大多数都支持该模式。如果你使用MosDNS，可以使用 mosdns probe pipeline {tcp|tls}://server_ip[:port] 测试命令测试服务器是否支持。比如 mosdns probe pipeline tls://8.8.8.8 。

          什么是ECS(EDNS Client Subnet)？

          ECS(EDNS Client Subnet)是扩展DNS查询的一种机制，旨在提升内容分发网络（CDN）和地理位置相关的服务的效率。通常DNS服务器只看到客户端的IP地址，但通过ECS，DNS请求会包含客户端IP的一部分（子网信息）。这样，内容分发网络可以根据客户端的地理位置，返回更接近用户的服务器，减少延迟，提升性能。ECS主要用于优化网络和加速服务的访问，但也可能带来一定的隐私泄露风险。
          测试了几家主流 DNS 的 ECS 功能 - V2EX
          DNS - @baraja - 这几天折腾了一下自建 AdGuard Home 的上游 DNS ，发现某些号称支持 ECS 的 dns 比如 nextdns 、cloudflare-gateway 都不太适合作为 AGH 的上游。因
          测试了几家主流 DNS 的 ECS 功能 - V2EX
          https://www.v2ex.com/t/1086059
          测试了几家主流 DNS 的 ECS 功能 - V2EX

          什么是DOH（DNS over HTTPS）？

          DoH（DNS over HTTPS）是一种技术，用来加密你的DNS查询。通常情况下（UDP及TCP协议情况下），DNS查询是明文的，容易被ISP运营商看到和监控。而DoH会通过HTTPS协议加密这些查询，确保你的请求内容是安全的，不会被ISP和运营商偷看。就像你在发送加密的信息一样，DoH保护了你上网时的隐私，并在一定程度上可以避免DNS劫持。

          什么是ECH（Encrypted Client Hello）？

          ECH（Encrypted Client Hello）是一种技术，用来加密你访问网站时的SNI（服务器名称指示）信息。通常情况下，当你想访问某个网站时，这个请求是明文的，运营商或其他第三方可以轻易看到你在访问什么网站，并可能进行拦截或阻断（例如SNI阻断）。这也是为什么有时你在国内访问GitHub和Linux.DO会遇到Time Out问题的原因之一。有了ECH，这些SNI信息就被加密了，外面的人就看不到你要访问哪个网站，从而提高了你的隐私和安全性。简单来说，ECH就像是在发送加密的信息，让你的浏览行为更加私密。

          什么是DNSSEC(Domain Name System Security Extensions)？

          DNSSEC(Domain Name System Security Extensions)是DNS系统的安全扩展协议，通过数字签名技术来确保DNS记录的真实性和完整性。它通过建立从根域名到下级域名的信任链，使用公私钥对对DNS记录进行签名和验证，能有效防止DNS欺骗和缓存污染。DNSSEC引入了几个关键记录类型：DNSKEY用于存储域名公钥，RRSIG包含数字签名信息，DS记录用于下级域委派签名，以及NSEC/NSEC3用于提供域名不存在的证明。虽然DNSSEC的配置较为复杂，可能增加DNS服务器负载并导致响应包变大，但它在防止DNS劫持和欺骗方面发挥着重要作用，目前已得到Google DNS (8.8.8.8)和Cloudflare (1.1.1.1)等主流公共DNS服务器的支持。

          其他关于DNS选择的文章？

          关于DNS选择，也可以参考：如何选择适合的公共DNS？ [2020] - Sukka's Blog
          💡
          有关DNS上的问题，欢迎您在底部评论区留言，一起交流~

          以太坊（ETH）公共RPC节点推荐

          2023-03-25 08:00:00

          😀
          以太坊（Ethereum as known as ETH）是一种基于区块链技术的开源平台，支持智能合约（Smart Contract）、去中心化应用（DApps）以及加密货币代币发行（Token）等功能。作为一个分布式系统，以太坊网络由众多节点组成，并通过公共RPC（Remote Procedure Call）接口提供与其他节点通信的方式，可以将RPC理解为提供接入区块链网络的入口，类似一扇门，我们所有在ETH链上的交易，均需要通过这扇门才能进行。本文将介绍以太坊的公共RPC节点。
           

          📝 什么是以太坊公共RPC节点？

          以太坊（ETH）公共RPC节点是一种与以太坊网络进行交互的方式，通过RPC，允许开发人员查询区块链数据、广播交易以及执行智能合约（Smart Contract）等操作。这些节点由不同的服务提供商托管，可以通过使用HTTP或WebSocket协议连接到它们，并通过节点提供的JSON-RPC接口与以太坊的区块链网络（ETH Mainnet）通信。

          🤗 为什么需要以太坊公共RPC节点？

          在链上交互、交易时，程序需要与以太坊网络进行交互时，或者作为开发者在开发DApps和智能合约时，在自己的节点上运行完整的以太坊客户端可能会很耗费资源和时间。相反，使用公共RPC节点可以更快地获取数据和执行交易，同时还可以节省部署和维护以太坊节点所需的成本。
          在ETH拥堵的时候，通过切换公共RPC节点，选择延迟较低的RPC入口，减少延迟，避免塞车，加快交易速度，抢占先机。需要注意的是，切换RPC节点，并不能降低Gas费用，RPC解决的是区块链的入口问题，而不是解决整条链的性能与费用问题。

          📎 常用的以太坊公共RPC节点有哪些？

          1. https://mainnet.infura.io - Infura是以太坊和IPFS的托管节点服务，提供了以太坊主网和测试网络的RPC节点。
          1. https://cloudflare-eth.com - Cloudflare提供的以太坊主网RPC节点。
          1. https://api.mycryptoapi.com/eth - MyCrypto API提供的以太坊主网RPC节点。
          1. https://rpc.slock.it/mainnet - Slock.it提供的以太坊主网RPC节点。
          1. https://eth.rpc.rivet.cloud - Rivet提供的以太坊主网RPC节点。
          1. https://mainnet-rpc.dexon.org - Dexon提供的以太坊主网RPC节点。
          1. https://eth-mainnet.alchemyapi.io/v2/{API_KEY} - Alchemy提供的以太坊主网RPC节点，可申请私有api key使用。
          1. https://rpc.moonriver.moonbeam.network - Moonriver提供的以太坊主网RPC节点。
          1. https://eth.rpc.tor.us - Torus提供的以太坊主网RPC节点。
          1. https://mainnet-rpc.thundercore.com - ThunderCore提供的以太坊主网RPC节点。
          1. https://rpc.ankr.com/eth - Ankr提供的ETH主网RPC节点。付费版本支持Websocket协议。
          1. https://quicknode.com - 提供支持DApp构建者使用的专业以太坊RPC和Web3 API接入服务。需要注册，免费版提供http provider和wss的API。
          1. https://eth.llamarpc.com - llamarpc提供的以太坊主网RPC节点，提供隐私保护
          1. https://eth.drpc.org - drpc提供的以太坊主网RPC节点，提供隐私保护
          以上这些节点，都是由相对知名与安全的厂商提供，例如Cloudflare，借助他们的服务调度与边缘计算网络，能够更快、就近实现接入ETH网络，实现交易。在选择上，我一般是对这些节点都做测速，选择延迟最低的来使用。同时，例如Alchemy这种需要自己申请api key的节点，在访问请求数量上会相比其他节点更少一些，所以速度上也会较快一些。
           

          英文版本

          Recommended-eth-public-rpc-nodes
           
          💡
          有关Notion安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~

          Recommendation of ETH Public RPC Nodes

          2023-03-09 08:00:00

          💰
          Ethereum (ETH) is an open-source platform based on blockchain technology that supports smart contracts, decentralized applications (DApps), and functions such as cryptocurrency token issuance. As a distributed system, the Ethereum network consists of numerous nodes and provides a way to communicate with other nodes through a public Remote Procedure Call (RPC) interface. RPC can be understood as an entry point for accessing the blockchain network, much like a door. All transactions on the ETH chain require this door to be accessed. This article will introduce public RPC nodes for Ethereum.

          What is an Ethereum public RPC node?

          An Ethereum (ETH) public RPC node is a way to interact with the Ethereum network, allowing developers to query blockchain data, broadcast transactions, and execute smart contracts through RPC. These nodes are hosted by various service providers and can be connected to via HTTP or WebSocket protocols, communicating with the Ethereum blockchain network (ETH Mainnet) through the JSON-RPC interface provided by the nodes.

          Why do we need Ethereum public RPC nodes?

          When interacting and trading on the blockchain, programs need to communicate with the Ethereum network. Running a complete Ethereum client on one's own node as a developer when developing DApps and smart contracts can be resource-intensive and time-consuming. Instead, using public RPC nodes can allow for faster data retrieval and transaction execution while saving costs associated with deploying and maintaining an Ethereum node.
          During times of ETH congestion, switching public RPC nodes and selecting RPC entry points with lower latency can reduce delays, avoid traffic jams, increase transaction speed, and gain a competitive edge. It is important to note that switching RPC nodes does not necessarily reduce gas fees. RPC solves the problem of access to the blockchain rather than addressing the overall performance and cost issues of the entire chain.

          What are some commonly used public RPC nodes for Ethereum?

          • https://mainnet.infura.io - Infura provides hosted node services for Ethereum and IPFS, offering RPC nodes for both the Ethereum mainnet and test networks.
          • https://eth-mainnet.alchemyapi.io/v2/{API_KEY} - Alchemy offers an Ethereum mainnet RPC node, with a private API key available upon request.
          • https://eth.rpc.tor.us - Torus manages an Ethereum mainnet RPC node.
          • https://rpc.ankr.com/eth - Ankr provides an ETH mainnet RPC node. Their paid version also supports the WebSocket protocol.
          These nodes are all operated by reputable and secure vendors, like Cloudflare. They leverage service scheduling and edge computing networks to achieve faster, more localized access to the ETH network, facilitating transactions. When choosing a node, I typically run speed tests on all options and pick the one with the lowest latency. It's worth noting that nodes requiring API key applications, such as Alchemy, often have fewer access requests than their counterparts. This can result in improved speed.

          青龙面板错误解决方法小全

          2023-03-01 08:00:00

          😀
          本篇文章旨在记录并解决目前我在使用Docker运行青龙面板（qinglong）薅京东羊毛时所遇到的问题，包括各种疑难杂症、依赖问题、报错问题。希望可以对其他人有所帮助，我会持续进行更新，请善用ctrl-f进行搜索。有人问青龙面板除了挂京东之外，还能挂什么？ 现在除了挂京东之外，其他都没有什么收益，就专心薅东哥羊毛吧，不是黑号的情况下，每个月1000京豆还是有的。

          📝 青龙面板问题列表

          1. 运行日志提示：cookie.match is not a function

          cookie相关脚本出现问题，删除任务之后重新拉库解决

          2. bizCode, bizMsg, lxml依赖问题

          目前已基本没有脚本依赖这三个，大部分教程已经过期，alpine包仓库里也已经移除这三个程序。
          如果需要安装bizCode、bizMsg依赖，需要先安装alpine-sdk、autoconf、automake以及libtool依赖，这样的话，整体Linux部分依赖就是，注意顺序：
          整体的Linux依赖安装时间较长，请耐心等待。
          在依赖安装过程中，安装过程中可能日志中可能会出现：
          建议自查网络是否存在问题。
          另外还有一种办法就是使用Debian镜像版本的青龙，docker-compose文件为：
          如果你的青龙面板部署在旁路由上，和科学上网插件在同一台机器，建议使用Docker的host模式，避免因为网络问题所产生的报错：

          3. 青龙日志分析 && 自动补全依赖提示：

          这种情况一般是因为拉了多个库，存在多个日志检测脚本文件造成的。通过添加环境变量：
          通过指定运行的日志检测脚本的绝对路径，让其他日志检测脚本检测到路径与此变量不符将停止运行

          4. 微信签到红包报错

          账号是黑号，没必要挣扎了。

          5. Faker2库拉取失败，点击链接提示404

          Faker2库的拉取命令为：
          其中，使用git.metauniverse-cn.com用于Github的加速，如果拉库失败，且点击链接提示404，可在开启科学上网的情况下，使用不加速Github的拉库命令：

          6. 总看到助力池，那助力池是什么？如何使用助力池进行助力？

          参考这篇文章：《如何加入京东助力池？》

          7. Python3依赖安装失败

          例如ping3、canvas、jieba、PrettyTable等。这些Python的依赖安装报错大概为：

          解决方法（1）

          主要都是集中在pip发现有多个版本的该Python包，无法选择使用哪个。这个问题一般是由于pip 版本问题导致的，我们需要对docker内的pip版本进行更新。步骤如下：
          1. 通过SSH进入Docker内的Bash命令行
          1. 更新pip版本
          1. 添加Linux依赖
          在青龙的依赖管理中，Linux部分添加如下依赖：
          1. 重新执行ping3、canvas、jieba、PrettyTable等Python3的依赖安装。

          解决方法（2）

          如果解决方法（1）没有解决Python依赖安装报错问题，那么可能是网络问题导致的依赖下载超时。建议修改Docker网络模式为HOST宿主模式，这种问题一般出现在青龙面板和科学上网同时都部署在旁路由上导致，Docker无法正常使用旁路由的分流。如果你使用的是Clash系列的插件，也可以在青龙面板的配置文件中修改ProxyUrl 为你的插件所提供的socket5或http代理地址及端口，例如OpenClash的为http://127.0.0.1:7890
          使用Host模式的Docker-Compose文件：

          8. Ninja面板扫码登录不跳转

          Ninja扫码登录京东之后未跳转，这个是青龙面板的版本问题。2.18.2版本的青龙面板不再使用/ql/data/config/auth.json 存储登录鉴权信息，所以Ninja无法写入JD Cookie，造成扫码登录京东之后不跳转，JD Cookie也未更新。
          遇到此问题建议更换青龙面板为较老版本。

          9. 青龙面板拉库提示脚本添加失败(jwt malformed)

          具体表现为拉库成功，但是添加脚本失败，大概的类似日志如下：

          解决办法

          在docker shell中运行如下命令：
          命令大概意思为添加tslib依赖，并重新检查青龙面板的依赖关系，并对存在问题的部分进行自动修复。
          然后再次执行拉库命令即可，这里使用的是faker4的纯净版脚本库：