ClouDNS .asia免费域名 托管到CloudFlare开CDN白嫖Websocket WS通道翻墙 / desec.io

点击标签看相关主题:

 

你以为的操作流程

操作 Cloudns

注册 www.cloudns.net 略

登录之后，

前缀随便取一个顺眼的.

后缀 不要选 .cloudns.cl (我试过, 添加不了 Cloudflare)

.cloudns.asia 可以.

* 欢迎大家在评论中分享哪些后缀可以使用.


操作 Cloudflare

注册 www.cloudflare.com 略

Add site

把你在 Cloudns 申请的域名写进去. 注意是域名全名, 别只写前缀. 应该是类似下面这样:

xxx.cloudns.yyy

滚到最下面, 选 免费的 plan

一路 下一步,

注意这两个 nameserver

切换到 Cloudns 

把原有的 NS 设置都删除

添加 NS 类型的 DNS 记录 

* 注意, Cloudflare 告诉你的那 2 个 nameserver 都要添加

添加完应该是像这样子的

切换到 Cloudflare

下一步让 Cloudflare 检查你刚刚设置的 nameserver, 然后耐心等一下.

检查通过后, Cloudflare 会给你发通知邮件的.


然后, 你可以按你以前学习的方式添加DNS解析.

比如, 像下面这样

但, 这时候你会发现不对劲. 不管等多久, DNS解析都不生效.

接下来就要搞一些骚操作.


在VPS上申请域名的证书

在 Cloudns 设置 DNS 解析到真实IP地址

我这个小鸡是 IPV6 的, 那么就添加 AAAA 记录. 如果你的小鸡是 IPV4 的地址, 那么添加 A 记录.

申请域名的证书

略.

* 不管你的证书是caddy自动申请的, 还是acme脚本申请的. 凡是需要域名解析到真实IP地址的情况, 都要在 Cloudns 上设置. Cloudflare上面的域名解析是无效的. (感谢 @smithnet 的指点)


如果你的VPS的IP没有被墙的话, 到这一步, 你搭梯子生成的节点应该是通的. (先不考虑速度的问题)

如果你是用的我的方案搭梯子, 用浏览器检查  域名 应该显示伪装站, 用浏览器检查  域名/path 应该显示 400 bad request.

* 如果不是这样的结果, 说明到目前为止你出现了问题. 不要盲目继续, 先把目前的问题排查了再说.


打通 Cloudflare 的 CDN 通道

(感谢 @smithnet 的指点)

在 Cloudns 设置域名解析到 Cloudflare 的IP范围

Cloudflare 的 IP 范围在此 https://www.cloudflare.com/zh-cn/ips/

挑选一个IPV4, 一个IPV6, 比如 

104.16.0.0
2606:4700::

Cloudns 中添加DNS设置, 像是下面这样


Cloudflare 打开 CDN (小黄云)


到此为止, 数据就可以通过 Cloudflare 的CDN网络翻墙来到你的VPS了.

数据链路是这样的:

1. 根据 Cloudns 的 DNS设置, 解析 [你的域名] 为 104.16.0.0, 所以数据包从你的 电脑 / 手机, 来到了 104.16.0.0 , 你可以理解为这是 Cloudflare CDN网络的其中一个服务器.

2. 然后 Cloudflare CDN网络看数据包中的 SNI 为 [你的域名]. 根据你打开了CDN的这个设置, 知道要把数据包送到CDN网络的另一端, 送到你的 VPS (真实IP地址).

* 如果还想学习更多知识, 请看: 连接 V2Ray Websocket + TLS 模式服务器的过程


但, 你发现不对劲

节点不通.

用浏览器检查 域名 并不能打开伪装站,  检查  域名/path 也不能看到 400 bad request. 而是显示下面这样的错误, 说这个网址不安全.

我们上一步不是明明申请域名的证书成功了的吗? 而且节点都测试过, 是通的. 

按以往的经验, CDN通道打通了就可以愉快地嫖 Cloudflarer 的 CDN 的 Websocket 通道了呀. 这是怎么回事呢?

感谢 Uncle LUO老羅叔叔的數字生活指南 提供的灵感. 接下来我们要解决证书的问题.


设置 SSL/TLS Edge Certificates 边缘证书

打开 Cloudflare 的 SSL/TLS 设置

 

滚动到下面一点, 展开. 可以看到为了验证你对域名有控制权, 需要添加这几个 TXT 类型的 DNS 设置

下图中, 1 和 2 是一组, 一个是 name, 一个是 value; 3 和 4 是另一组.

切换到 Cloudns 的 DNS 设置页面

添加 TXT 类型的 DNS 记录

注意, 主机 这一栏, 你需要填写的其实只是前缀 _acme-challenge , 后面那个 .xxx.cloudns.yyy 是不用填写的.

同样的, 再添加一个 TXT 记录.

需要耐心等一段时间, 直到 Cloudflare 验证完成. 变成绿色的 Active 像下面这样.

然后你的节点就可以正常使用了.

你用浏览器检查 域名 能正常打开伪装站,  检查  域名/path 能看到 400 bad request. 


如果还不行的话, 检查 SSL/TLS 加密模式为 完全 encryption mode is Full

* 要不要设置为 "完全/FULL" 和你得到证书的方式有关, 如果你是用的我的方案, 那么这里要设置为 完全/FULL


完


========

后记

后缀 不要选 .cloudns.cl (我试过, 添加不了 Cloudflare)

感谢网友的分享! 本文整个方案并非我原创, 我只是尽量写成一篇流畅的教程而已.


========

同理

https://desec.io/ 也可以来申请一个. 完全一样的流程.

不过在添加 NS 记录时, 尾巴后面多加一个 .

在添加 TXT 记录时, 要求用双引号把那一大串包起来.



========

Update

还有一种让Cloudflare的解析生效的方法

例如, 我要设置 pastebin.icdyct.cloudns.asia 在Cloudflare上的解析+CDN生效, 这样才可以将其设置为我的 worker 的域名.

在Cloudns中设置 pastebin.icdyct.cloudns.asia 的 NS 解析为 Cloudflare 的namesever:


再按 Cloudflare 的边缘证书的要求设置 TXT 解析

https://pastebin.icdyct.cloudns.asia/tieludasiliqiuweiyue 是一个网络记事本. 你可以来试试.


评论

  1. treasure十二月 18, 2023

    谢谢。

    回复删除
  2. ǝɔɐǝԀʎzɐɹƆ十二月 25, 2023

    同样的二级域名, https://desec.io/ 也可以来申请一个.

    回复删除
  3. 禅猫一月 18, 2024

    能自选节点不？

    回复删除
  4. Dash三月 15, 2024

    20240315，现在只有 dns-dynamic.net / cloudns.be / cloudns.ch 这三个免费二级域名了，这三个试了都绑定不了 clouflare

    回复删除
  5. zivan三月 18, 2024

    请问博主，用worker的自定义域名访问worker，和给worker设置routes访问，有什么区别？

    回复删除

发表评论

The Hot3 in Last 30 Days

用浏览器 检测Reality伪装效果 是否搭建成功 排错Troubleshoot

图片
Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的.
Read more »

233 sing-box 脚本 TCP 端口转发 Reality 协议 排错 Troubleshoot

图片
233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...
Read more »