【第108期】【免费域名21期】cloudns（be、ch、net后缀）的域名托管到cloudflare后的双向解析！活用泛域名解析！引入代理IP&再次精简DNS记录后，测试优选IP！结果会如何呢？

→★★★本系列持续更新中，敬请关注！★★★
该网站免费域名托管到cloudflare后需要双向解析！活用泛域名解析，可以避免在cloudns里添加太多DNS记录！主要适用于以下场景：
该网站免费域名托管到cloudflare后需要双向解析！活用泛域名解析，可以避免在cloudns里添加太多DNS记录！主要适用于以下场景：
1，域名绑定cloudflared tunnel：
添加一条隧道服务产生一条CNAME记录，泛域名解析到该CNAME记录！之后在cloudns侧加入双向解析的3条DNS记录！每添加一条隧道服务，都会在cloudflare侧自动生成一个CNAME记录，cloudns侧DNS记录不变！（★★★免费域名第9期★★★）
2，域名绑定云服务器等公网IP：（VPS侧有traefik的SNI服务）
添加一条A记录，指向VPS，泛域名解析到该A记录！之后在cloudns侧加入双向解析的3条DNS记录！随着VPS侧traefik的SNI服务的增加，cloudflare和cloudns的DNS记录不变！
（★★★免费域名第10期★★★）
→前两期视频做完后，因为场景1的*记录在场景2被修改（tunnel.swing.cloudns.be→isp.swing.cloudns.be），原以为修改后只有场景2的域名可访问，事后发现场景1，2出现的域名都能访问到！（★★★免费域名第11期★★★）
以前x10的免费域名时，两个场景是用了不同的域名后缀：
场景1：x10.mx
场景2：x10.elementfx
故而没有发现这个问题！而cloudns一个免费帐号目前只允许最多一个免费域名，是用一个域名做的两种场景展示，发现了这个现象！
另外，场景1中隧道中定义的几个服务与traefik中同名：
1，tunnel.swing.cloudns.be
2，nps.swing.cloudns.be
3，wg.swing.cloudns.be
→1，3实际上与traefik中并不是同一个服务！因为同名的问题，影响了cloudflare的域名解析，导致访问traefik的gost-tunnel服务时，走了隧道的CNAME记录，意外访问了隧道的tunnel（openwrt服务）！
为了消除上述同名引起的现象，特将traefik中的几个服务重新命名，加上-t便于区分，有助于后续的原因分析！（★★★免费域名第12期）
1，tunnel-t.swing.cloudns.be
2，nps-t.swing.cloudns.be
3，wg-t.swing.cloudns.be
4，frp-t.swing.cloudns.be
原因分析：（★★★免费域名第13期★★★）
■场景1的隧道服务tunnel.swing.cloudns.be可以访问，容易理解：
两边都添加了tunnel的DNS记录！
（cloudns侧：两条tunnel的NS记录，cloudflare侧：一条CNAME记录）
■场景2的frp-t.swing.cloudns.be等4条记录可以访问，也容易理解：
(以frp-t.swing.cloudns.be为例）
1，frp-t.swing.cloudns.be匹配了cloudns侧*绑定的isp.swing.cloudns.be（2条NS记录）
2，cloudflare侧isp.swing.cloudns.be是一条A记录，指向VPS
■场景1的隧道服务nps.swing.cloudns.be、wg.swing.cloudns.be：
1，匹配了cloudns侧*绑定的isp.swing.cloudns.be（2条NS记录）
2，再来到cloudflare侧找时，因为nps和*的CNAME记录同时存在，优先匹配nps记录
估计很多观众与我有过类似经历：
申请了可以托管到cloudflare上的二级域名，兴奋冲冲地托管到cloudflare上添加了DNS记录，结果发现解析不了，上网一查发现要双向解析！在域名原申请网站也添加DNS记录后才解析生效！
→由此可见，这种域名在解析时是有一个先后顺序的，先看原申请网站的DNS记录，后看cloudflare侧的DNS记录！
所以，场景1的nps.swing.cloudns.be：
1，先看cloudns侧，因为没有nps的DNS记录，匹配了*泛域名解析，找到了isp.swing.cloudns.be的NS记录，指向cloudflare！
2，因为cloudflare侧存在一条nps的CNAME记录，相比*指向的A记录（isp.swing.cloudns.be），优先匹配！也就是说在cloudflare侧，找不到nps.swing.cloudns.be的时候，才会匹配*泛域名解析！
→故而，我们访问到了场景1的nps.swing.cloudns.be指向的隧道服务！（CNAME记录）
虽然它在cloudns侧没有定义，匹配了cloudns*泛域名解析的isp.swing.cloudns.be指向的A记录！
■结论：
1，匹配*的泛域名解析之前，如果该域名存在，优先匹配！
2，cloudns和cloudlare侧的DNS记录可以有差别！
→基于以上结论，在cloudflare侧做点小动作：（★★★免费域名第14期★★★）
以上小动作有如下好处：
1，通过泛域名解析，我们不需要在cloudns测不停添加DNS记录！
2，突破50条记录的限制。之后只在cloudflare侧添加！即使超过50条，理论上应该也没有问题！
■DNS记录精简：
关于场景1的隧道服务，场景2的SNI多域名指向同一个IP的用法，许多人可能并不需要，我们对DNS记录作一下精简，以符合平常添加cf域名的习惯！
（★★★免费域名第15期★★★）
cloudflare侧：
*的泛域名解析：保留（指向isp.swing.cloudns.be）
isp.swing.cloudns.be的A记录：保留（随意一个公网IP）
cloudflare侧：
*的泛域名解析：保留（指向isp.swing.cloudns.be）
isp.swing.cloudns.be的两条NS记录：保留（跟cloudflare侧保持一致）
swing.cloudns的两条NS记录：保留（为了托管到cloudflare）
_acme-challenge的两条NS记录：保留（为了激活cloudflare边缘证书）
■Cloudflare代理模式（开启小云朵）下的限制（★★★免费域名第16期★★★）
developers.clo...
解决办法：
1，端口转发到cloudflare允许的指定端口（参照上面的URL）
2，前置代理软件（如traefik）工作在允许的端口（如8443）下，绑定到后台服务（跟办法1类似）
3，两边都添加DNS记录
→如果你不需要cloudflare家的附加服务：
1，小云朵
2，隧道服务
3，worker（page支持CF托管以外的域名）
4，其它
可按正常域名的用法，只在cloudns侧添加记录即可！（★★★免费域名第17期★★★）
（其实之前的场景2，就可以只在cloudns侧添加记录）
■开启小云朵时，直接绑定PING命令显示的代理IP（★★★免费域名第18期★★★）
→代理IP和traefik工作机制的对比，一个巨大版的traefik？（★★★免费域名第19期★★★）
→引入代理IP后再次精简DNS记录（★★★免费域名第20期★★★）
→用优选IP替换cloudflare自动分配的代理IP（★★★本期★★★）
前提：
1，cloudflare帐号
2，cloudns免费域名
3，cloudns免费域名托管到cloudflare，并激活（2条NS记录）
4，cloudflare边缘证书激活 （2条NS记录或TXT记录）
5，下载好优选IP批处理
筛选程序：
gitlab.com/Mis...
■执行优选IP批处理，选1（IPV4）：
打开生成的result.csv，找到第一行的优选IP
■修改cloudns侧的*泛解析记录：
主机名：*
指向到：162.159.192.17（优选IP）
等待15分左右，DNS记录生效！
（★★★因为DNS缓存的问题，部分DNS记录还没有生效，我们用另一台PC测试★★★）
■浏览器中验证cloudflare中的DNS记录：（特别是在cloudns侧不存在的DNS记录）
yahoo1.cloudns... （成功）
yahoo2.cloudns... （成功）
yahoo3.cloudns... （成功）
yahoo4.cloudns... （成功）
nps.swing.clou...（成功）※场景1中隧道服务添加的CNAME记录
frp-t.swing.cl... （失败） ※场景2中的的主机名
（★★★在录屏机可以访问，应该是因为DNS缓存的问题★★★）
traefik2.swing.... （失败） ※之前视频演示端口限制添加的记录
（★★★端口转发：gost -L tcp://:8880/:51831★★★）
（★★★演示时协议错误：https。http才是对的！但http其实也访问不了！★★★）
traefik.swing.c... （成功） ※cloudns侧存在的DNS记录
（★★★演示时进行了协议更正：https→http★★★）