【杂谈】从网络看CloudFlare自选IP（附憨憨扫描方法）

发布于 2020年3月8日 / 日常杂谈 / 136 条评论

CloudFlare自选IP在站长圈子里传的应该还是比较广泛的，虽然CF使用了Anycast技术，但是在路由的配置上，不同的IP段路由存在着些许的不同，有时候我们可以自己选择对当前网络相对优秀一些的IP来提升CDN的速度。

写这篇文章，主要还是从宏观的线路上谈起，不可否认部分地区由于穿透等原因使得到某些节点效果很好，但那是偶然现象，这里还是从运营商层面来谈合适与否。

其实作为一个大流量的CDN提供商，流量是它支出的大头，不难看出它接驳的运营商主要是大型IX和Tier1运营商，因为它们的带宽相对便宜。举个简单的例子，CF到HKIX的200Gbps容量在年初可能是因为疫情原因趋于饱和了，官方将分配给Free/Pro的IP段香港访问路由切到了新加坡日本等地，只有Enterprise的段依然是HKIX。原因其实很简单，HKIX即使是香港最便宜的商用带宽，价格相比于日本、新加坡也是高出很大一截，如果要在本地满足香港本地所有的互联，支出是比较大的。想一想大陆骨干网接入的的带宽价格，你能理解CF没有进一步对大陆优化的原因了吧。

当然这里插一句，国内的带宽价格也是符合当前国情的，以商用宽带补贴家用宽带。世界上能够支撑低价、高速的网络的一般都是面积较小的地区（如香港、新加坡等），它们在内部骨干网建设上不需要投入太多的资金，即使小型运营商也能完成城市的网络覆盖。像美国等国土面积较大的国家，一般是家宽反补商宽的策略，与你能够买到的低价VPS不同，民用宽带的平均月费在$100以上，并且美东很多地方还停留在Cable（同轴电缆）入户的阶段。

所以请放弃对于CF为啥不接PCCW、SoftBank之类的幻想，它们太贵了。那么既然CF选择了较为廉价的带宽，很不幸，廉价的带宽卖给其他的机房也很便宜，所以CF到中国大陆的互联肯定谈不上非常优秀，在使用它建站之前就需要摆平这样的心态。

CF的路由经常进行调整，文中的配图仅供参考，后续应该不会更新。

一、电信

中国电信作为区域顶级运营商，除欧美外接入服务均不是免费的。就像NTT到电信为啥那么堵，因为NTT只买了45Gbps到电信的容量啊，想要扩容需要NTT再向电信购买。电信能够走到CF的路由很少，因为作为接近顶级的运营商，它只向Level3购买了Tansit，所以不会有其他的能够到CF的路径了。

IP Tansit：互联网运营商骨干网之间的互联主要有两种，一种是对等或不对等的网间互联Peer，这种是存在双方利益的、用于双方互通的链路；另一种是Transit，由弱势方向强势方购买，让强势方通过自身网络为弱势方提供到第三方网络的链路。

运营商评级：国际上对于运营商的评级是根据覆盖来的，具体而言就是看是否购买了Transit。顶级运营商Tier1自身连通性很好，不需要Transit来打通到其他运营商的链路。区域顶级运营商就是Tier2，如电信联通等就是能够以少量的Transit完成互联。至于Tier3，就像移动AS9808这种，完全依赖Transit完成全球互联。当然运营商评级并不反映运营商的网络质量和规模，如印度的TATA和美国Cogent等，网络稳定性和传输容量并不是顶级的。而很多Tier2比如电信，国内随便一个省级汇聚的容量都可以达到数T级别，相比之下北美一个州的所有流量汇聚才几百G级别。

北美163（圣何塞/洛杉矶）

CF在洛杉矶和圣何塞接入了300G的带宽到电信的POP，首先这点容量不太多（CERA洛杉矶机房都接入了1.2T），其次是北美的POP到国内汇聚这一段容量也不够，高峰期使用不会太顺畅。总体而言洛杉矶表现好于圣何塞（但是这个经常调整），同时根据电信汇聚负载的情况，各负责层质量广州＞上海＞北京。

欧洲Level3（德国/荷兰/英国）

前面也说了电信购买了Level3的Transit，理论上到北美也能这么走，但是可能是路由链长吧并没有这么走的。不推荐电信使用欧洲的节点，一是电信到欧洲POP的容量显然小很多，其次欧洲低价带宽更多，拥堵状况肯定比北美要严重一些。但是如果你源站在欧洲，有兴趣可以自己试一试吧。

电信CN2

以下内容由@sparktour补充，在此表示感谢(￣▽￣)”。CN2毕竟属于精品网，上级Transit很多而且冗余比较多，选一个离得比较近的节点就可以了。

节点地址	路由
香港	CN2 => 香港NTT => CF
新加坡	CN2 => 香港NTT => 新加坡NTT => CF
东京/大阪	CN2 => 香港NTT => 日本NTT => CF
巴黎	CN2 => 伦敦Level3 => 巴黎Level3 => CF
阿姆斯特丹	CN2 => 伦敦Level3 => 阿姆斯特丹Level3 => CF
法兰克福	CN2 => 伦敦Telia => 巴黎Telia => 法兰克福Telia => CF
圣何塞	CN2 => 圣何塞Telia => CF

二、联通

联通其实跟电信也差不多，都是Tier2运营商。好在自身汇聚的负载比较小，再就是没电信那么强势，选择稍微多一些。

圣何塞gtt

联通走gtt到CF慢，说实在还真不是联通的问题，到圣何塞gtt走的是上海-圣何塞的链路，主要是圣何塞gtt接入CF的容量不够，只是晚高峰有丢包现象。

洛杉矶gtt

到洛杉矶和圣何塞是根据国内不同省份随机的，路由是广州-洛杉矶链路，表现会比圣何塞gtt好一些，较为推荐。

圣何塞Cogent

Cogent圣何塞的问题比较大，不光到联通堵，到CF也堵，强烈不推荐。另外与国内三大运营商的互联中，建议绕开一切走Cogent的，质量相当感人。

其他北美gtt

目前扫到的有西雅图、芝加哥、纽约等，但是这些由于距离较远，虽然丢包低于圣何塞但是延迟普遍上到了260+ms，不推荐。

欧洲gtt

欧洲gtt是目前联通访问最稳定的方向，推荐使用，得益于联通目前到欧洲的负载比较低。扫到的有德国、布鲁塞尔、法国等，质量差距不大，但是广州联通到欧洲延迟异常的高，推测可能是回程绕美。

芝加哥Verizon

这个段比较特殊，Verizon的网一向是给联通AS9929使用的，给AS4837使用的情况比较少；印象中联通走Verizon的速度是很稳定的，CF这个没有实际测试速度，但是延迟不是很理想。

日本NTT

曾经联通有走广州直连NTT的段，后来CF拔掉了，剩下去程绕北美Sprint的段，再后来就彻底拔掉了。现在只有IPv6能够通过NTT到日本，但是联通IPv6到NTT有一点点拥堵的情况，还算可以，但是不大推荐用。

三、移动

移动作为一个Tier3运营商，骨干网比较便宜，而且为了连通性支持通过CMI购买了很多的Transit，再加上亚太地区有开放的Public Peer，能够在亚太地区直连CF。移动广州CMNET-香港CMI段有大概900G的容量，到CF卡顿主要是这一段负载比较高，所以访问质量并不一定能比得上联通，而且以下列出的亚太链路基本都受这一段拥塞的影响。

另外就是移动的路由有明显受到地区影响，主要分为北方移动（北京负责层，包括东三省以及华北等）和南方移动（广州负责层，包括华中华南等），这两个大片区收到的路由策略略有差异，后文就不再区分这个概念。

香港CMI直连

CMI直接跟CF有互联，一方面也是给CMHK的用户用的吧，香港这几个互联质量好坏说不清楚。

洛杉矶CMI直连

2020年9月CMI（China Mobile International）与CloudFlare在洛杉矶建立了新的对等互联。副作用就是其路由链长度比HKIX更短，也就导致了HKIX的IX路由无法接收。整体而言移动到北美POP的带宽是很有限的，不推荐使用。

德国CMI直连

2020年10月CMI（China Mobile International）与CloudFlare在德国建立了新的对等互联。互联初期丢包较少，但是速度并不是特别理想。移动到欧洲的POP容量理论上是小于北美的，后续稳定性大概率无法保证。

香港HKIX

移动CMI在香港跟HKIX有200G的互联，而且是Public Peer，大多数访问都走HKIX。质量差不多，建议自测，不过有部分IP段北方移动跑Cogent去了，记得特别关注一下。由于2020年9月CloudFlare与CMI在洛杉矶建立了对等互联，导致了HKIX的路由链长于北美，此路径目前理论上已经无法走到了。

香港NTT

移动在香港也接入了容量比较大的NTT，但是CF香港主要的回源线路就是NTT，跟上面俩也差不多，好坏需要自己去测一测。

新加坡NTT

新加坡NTT有时候有抽风的情况，延迟大幅升高，可能是回程绕美了，这个就不太推荐了。

日本NTT

日本NTT北方移动是走不到的，南方移动也是从香港走。一般不推荐香港以外的地方，毕竟都要过香港CMI，在本地一般比再出来走一段快一些；当然有些地方表现能好点，自己测吧。

日本Telstra（澳电）

澳电这个跟移动的带宽容量不大，北方移动走北京直接去东京的澳电，南方移动走香港CMI去澳电，质量也差不多。也有很大一部分南方走澳电，北方跑去Cogent的。

新加坡EQUINIX

这个是CF近期才接上的，南方移动部分IP段回程可能绕美，也有些不绕，质量也差不多。

北美Cogent

北方移动容易走到Cogent去，因为缺了香港CMI到Telstra的路由，质量很差，慎选。南方移动基本没有这么走的。

欧洲DECIX

移动的IPv6可以走香港-德国DEC-IX，CMI到DECIX是有100G的容量，也丢包，质量一般般，不推荐。前段时间本来v6能走HKIX直连的，但是不知道移动怎么想的似乎把来自HKIX的IPv6路由全部断掉了，以后能用了再说吧。

四、其他

其他里面主要是科技网和教育网，这两个科研网络现在都还是不是特别拥塞。科技网只有香港接驳的HKIX、Cogent和PCCW三个Transit，所以能够走到的路由也是很少的。

教育网=>>美国TATA

教育网=>>香港Telstra

科技网=>>香港HKIX

科技网=>>圣何塞/西雅图Cogent

科技网=>>加拿大Cogent

科技网=>>欧洲Cogent

五、扫描

在访问CF的节点时，节点后加上/cdn-cgi/trace能够获取到，其中h为节点IP；colo即为节点所在位置，采用的机场三字码表示，查询机场三字码：点击前往。

网页测试（推荐）

@TulvL之前写了一个网页测试colo和速度的工具，使用简便而且效率很高，博主进行了简单的修改使其支持更丰富的CF IP以及IPv6，测速功能和HTTPS以目前的形式无法实现所以不能使用。

便捷模式：http://cftest.120712.xyz
完整IPv4：http://cftest.120712.xyz/ipv4-all
完整IPv6：http://cftest.120712.xyz/ipv6
CF BYOIP：http://cftest.120712.xyz/byoip

脚本批处理

我这里采用的是比较笨的办法，由@犯罪高手想出来的，在此表示感谢。通过批处理将IP和Colo记录下来，后来我顺着他的思路修改了一下，让Linux上也能跑这个脚本。至于内容，你可以自行根据IP段用Excel生成。

我们需要扫描的段到/24就可以了（也就是IP四段中最后一段可以忽略），因为这是IP的最小广播单位，对于CF而言同一个C段的IP路由不会有太大的出入。

#Windows批处理
curl http://104.16.0.86/cdn-cgi/trace --connect-timeout 2 -m 2 | findstr "h= colo=" >> log.txt
#Linux Bash
curl --connect-timeout 1 -m 2 http://104.16.0.86/cdn-cgi/trace  | grep "h=\|colo=" >> colo.log

#Windows批处理

curl http://104.16.0.86/cdn-cgi/trace --connect-timeout 2 -m 2 | findstr "h= colo=" >> log.txt

#Linux Bash

curl --connect-timeout 1 -m 2 http://104.16.0.86/cdn-cgi/trace | grep "h=\|colo=" >> colo.log

CF的IP段官方有提供（点击前往），这里也提供一份别人总结的（点击下载），比较全面（如果作者看到希望联系一下加上您的信息，非常感谢）

在这里提供一份现成的脚本，curl超时的时间时2秒（2秒打不开一个单页这IP也没啥价值了）；里面IP段的顺序有些有点乱，不过不影响正常扫描，如果有需要自己去整理生成；当然能自己撸一个自动化的程序当然是最好的。

Windows .bat：点击下载
Linux .sh：点击下载

最后扫出来的结果差不多如图，有了地区，跑路由可以用Besttrace，对照我上面写的网络情况你可以简单做一个取舍。至于你想自己测试延时和丢包率也是可以的，毕竟各地网络条件不一样，你可以自己测试最适合你的，这些方面就不再赘述了。

@Silmace大佬提供了一个批量测试IP延迟和丢包率的脚本（点击前往），在此表示感谢(o゜▽゜)o☆

Python脚本

这个测试脚本是大哥@CZM写的，在此表示感谢；使用Python3.6即可运行，IP段请参考上表。

#http://104.16.0.86/cdn-cgi/traces

urls = ["http://104.16."+str(i)+".86/cdn-cgi/traces" for i in range(0,10)]
import aiohttp
import asyncio
import requests

async def get_request(url):
    async with aiohttp.ClientSession() as cs:
        async with await cs.get(url) as response:
            return await response.text()

def parse(task):
    print(task.result().split("\n")[6])

tasks = []
for url in urls:
    c = get_request(url)
    task = asyncio.ensure_future(c)
    task.add_done_callback(parse)
    tasks.append(task)

loop = asyncio.get_event_loop()
loop.run_until_complete(asyncio.wait(tasks))

#http://104.16.0.86/cdn-cgi/traces

urls = ["http://104.16."+str(i)+".86/cdn-cgi/traces" for i in range(0,10)]

import aiohttp

import asyncio

import requests

async def get_request(url):

async with aiohttp.ClientSession() as cs:

async with await cs.get(url) as response:

return await response.text()

def parse(task):

print(task.result().split("\n")[6])

tasks = []

for url in urls:

c = get_request(url)

task = asyncio.ensure_future(c)

task.add_done_callback(parse)

tasks.append(task)

loop = asyncio.get_event_loop()

loop.run_until_complete(asyncio.wait(tasks))

留言中@Yunen大佬提供了一个扫描header中colo信息的脚本，这个相比于curl效率更高，感谢大佬们的补充(￣▽￣)”

import requests, threading, queue

IPQueue = queue.Queue()
_WORKER_THREAD_NUM = 3

class Workers(threading.Thread):

    def run(self):
        while not IPQueue.empty():
            ip = IPQueue.get()
            try:
                rsp = requests.head('http://' + ip, timeout=2).headers
                print(ip, rsp['CF-RAY'])
            except:
                pass


def main():
    global IPQueue
    with open('cloudflare_ip.txt', 'r') as f:
        for ip in f.read().splitlines():
            IPQueue.put(ip)

    threads = []
    for i in range(_WORKER_THREAD_NUM) :
        thread = Workers()
        thread.start()
        threads.append(thread)
    for thread in threads :
        thread.join()

if __name__ == '__main__':
    main()

import requests, threading, queue

IPQueue = queue.Queue()

_WORKER_THREAD_NUM = 3

class Workers(threading.Thread):

def run(self):

while not IPQueue.empty():

ip = IPQueue.get()

try:

rsp = requests.head('http://' + ip, timeout=2).headers

print(ip, rsp['CF-RAY'])

except:

pass

def main():

global IPQueue

with open('cloudflare_ip.txt', 'r') as f:

for ip in f.read().splitlines():

IPQueue.put(ip)

threads = []

for i in range(_WORKER_THREAD_NUM) :

thread = Workers()

thread.start()

threads.append(thread)

for thread in threads :

thread.join()

if __name__ == '__main__':

main()

六、结语

本来说每种路由配张MTR图的，奈何十点过学校寝室好像断电了(╬▔皿▔)凸，等来电了再补上吧，翻聊天记录只找到了一小部分。

都说授人以鱼不如授人以渔，刚开始打算发几个IP段出来，后来想想算了。一是各地网络条件不同，路由也有细微的差异；再就是如果你一直直接伸手，那也没什么意思了。拿CF做代理的其实一方面是滥用，另一方面速度也一般吧，自己能接受当然CF也不在意。

想对于国内访问优化，如果你有那个闲心，华为云DNS提供免费的地域分线路解析，IPIP.NET提供了很多全国各地的节点，自己慢慢去测吧，提升还是会有的。

另外网站静态资源可以国内化，只从CF加载一个页面；比如同步到JSdelivr，有耐心的朋友可以自己去研究研究，这个就不写了。

最后还是祝各位建站愉快，文章中要有什么不准确的地方，请多多指教ヾ(≧▽≦*)o

*原创文章，转载请注明出处

# CloudFlare # 自选IP

转载原创文章请注明，转载自： Luminous' Home » 【杂谈】从网络看CloudFlare自选IP（附憨憨扫描方法）

CYF @TA
2020-09-20 上午7:44

移动最近出大问题，之前走CMI的CloudFlare在八月底突然改道，基本上所有流量都走向LAX，延迟飙升。以前走CMI-HKG时南方移动速度和延迟还是比较理想的，这么一搞彻底完蛋。也不知道是移动搞的鬼还是CloudFlare切走了QWQ
1. Luminous @TA 
  2020-09-20 上午10:58
  
  @CYF CF在洛杉矶买了移动的带宽，直接接入了CMI北美的POP，这样路由链就比走HKIX更短，以前走HKIX去CF的IP全部去了北美
  1. CYF @TA
    2020-09-20 上午10:59
    
    @Luminous 但是这样子反而比以前的HKIX还要难受，延迟变的异常的大，丢包率也比以前严重
    1. Luminous @TA 
      2020-09-20 上午11:01
      
      @CYF CF在香港和移动CMI也有购买的互联，比如104.19.0.0/16，北美带宽便宜啊，CF也是想省钱而不是给你优化
      1. CYF @TA
        2020-09-20 上午11:02
        
        @Luminous 非常感谢！
Pwndrer4 @TA
2020-09-13 上午11:15

这两天发现貌似cf把联通欧洲波动到西雅图了
1. Luminous @TA 
  2020-09-13 下午3:43
  
  @Pwndrer4 对，之前很多在法兰克福的段都切到北美了，现在还在法兰克福的IP段延迟都异常偏高，感觉像是回程绕美了
365cent @TA
2020-08-29 上午7:27

讲得很详细,感谢大佬分享
Pwndrer4 @TA
2020-08-22 下午9:22

求联通ipv6到日本的地址，谢谢
1. Luminous @TA 
  2020-08-25 下午7:51
  
  @Pwndrer4 现在测了一下似乎已经没有了……
  1. Pwndrer4 @TA
    2020-08-25 下午8:37
    
    @Luminous 实测了下，做下载站，移动连香港三个互联质量都不行，还不如电信联通连洛杉矶的快，不知道大家有没有同感联通连洛杉矶效果比想象中的好很多（下载速度不错）顺便请教下cloudflare的回源机制
    1. Luminous @TA 
      2020-08-25 下午9:03
      
      @Pwndrer4 移动看地区，我这里测试104.19段质量尚可，联通本身负载低其实到欧洲更好一些。CF自己没有全球骨干网，回源的话是路由到的节点所在地直接走运营商网络回源，如果你查阅CF的IP你能看到很多非Anycast的就是回源的段，比如香港地区回源主要就是走NTT、GTT，新加坡主要是TATA。
      1. Pwndrer4 @TA
        2020-08-25 下午9:37
        
        @Luminous 欧洲的话我担心我源站回源慢我源站在香港、新加坡、台湾均有部署（我担心联通走欧洲下载回源慢）
        
        Luminous @TA 
        2020-08-26 下午1:37
        
        @Pwndrer4 既然使用CF，建议源站安置在北美
        
        Pwndrer4 @TA
        2020-08-26 下午2:20
        
        @Luminous 嗯，谢谢
      2. Pwndrer4 @TA
        2020-08-26 下午9:47
        
        @Luminous 电信貌似下载起来速度洛杉矶圣何塞还有欧洲都很一般 200K这样子，即使缓存命中了还是我选的ip不行？求推荐个电信的ip端，源站在台北，谢谢
        
        Luminous @TA 
        2020-08-26 下午9:48
        
        @Pwndrer4 这个时间能200K已经很不错了，北美163拥塞状况你应该知道的
        
        Pwndrer4 @TA
        2020-08-26 下午10:38
        
        @Luminous 我用杭州阿里BGP测的发现这个ip表现较好 141.101.115.3 这些国内BGP出国走的应该是电信吧
        
        Luminous @TA 
        2020-08-26 下午11:14
        
        @Pwndrer4 总体拥塞，单一位置测试结果对于速度优化无意义
      3. Pwndrer4 @TA
        2020-08-26 下午9:49
        
        @Luminous 我用cloudflare的原因就是减少谷歌云流量支出
Xiaomage @TA
2020-08-21 下午8:07

北方移动到美西cf直连了，可以不经过cogent了刚刚路由追踪的结果
顺便求下转载一部分会注明来源哒~
i.loli.net/2020/08/21/drGTYImqO2k6s9i.png
1. Luminous @TA 
  2020-08-21 下午9:22
  
  @Xiaomage 确实是CF接入了CMI位于洛杉矶的POP，不过这并不是一个好的信号，CMI北美段拥塞程度远高于香港……
  1. Xiaomage @TA
    2020-08-21 下午10:54
    
    @Luminous 确实很卡...美西移动直连CF的LAX和SJC节点现在丢包都很高而且现在很难走hkix去香港了，只剩下移动香港CF直连，有些IP的丢包和延迟也是非常高，有的低一些，比较少丢包比较意外的是直连西雅图，不经过SJC和LAX的节点丢包很低
    1. Luminous @TA 
      2020-08-21 下午11:11
      
      @Xiaomage 移动北美POP到大陆的容量应该不超过500G，西雅图的POP接入的服务商比较少，可能是负载相对低一些吧……
致命吕布 @TA
2020-08-01 上午12:29

联通的9929走cf也是经过香港ntt的，之前长沙联通漏路由的时候穿透到A网过https://ibb.co/kBDY9kt https://ibb.co/z2xFY9v
1. Luminous @TA 
  2020-08-01 上午8:09
  
  @致命吕布 9929因为没有网络去测试，就先不提了，应该是去北美、欧洲、香港、新加坡、日本都有的，上游服务商比较多。
  1. 致命吕布 @TA
    2020-08-01 上午8:20
    
    @Luminous 大佬能推荐下电信走ntt的ipv6节点吗😂
    1. Luminous @TA 
      2020-08-01 上午8:21
      
      @致命吕布电信IPv6上游没有NTT
      1. 致命吕布 @TA
        2020-08-01 上午8:51
        
        @Luminous 那电信和cf之间能走的估计只有北美163和欧洲了😂，还真是世界加钱可及
Yunen @TA
2020-07-20 上午4:23

扫机场的内个py脚本用GET不太好，建议换成HEAD扫描，CF-RAY字段也带有机场简写信息。这是我随便写的新的扫描脚本：https://paste.ubuntu.com/p/NX9rx5BHyh/
1. Yunen @TA
  2020-07-20 上午4:26
  
  @Yunen 这默认的个人站点居然是QQ空间...
  1. Luminous @TA 
    2020-07-20 上午10:49
    
    @Yunen QQ号方便，不用的话其实可以空着的(づ￣ ³￣)づ
2. Luminous @TA 
  2020-07-20 上午10:48
  
  @Yunen 非常感谢您的补充(｡･ω･｡)ﾉ♡，等一会用电脑的话我会补充到文章中哒
zzzyc1 @TA
2020-06-11 上午9:50

大佬你好！我很想知道关于运营商线路还有级别，流量大小这方面的资料是在哪里收集的呢？我一直对网络这方面感兴趣，不知道在哪里有这些比较准确的数据。
1. Luminous @TA 
  2020-06-11 上午9:59
  
  @zzzyc1 没有具体数据，公开的的peer可以在PeeringDB查到
  1. zzzyc1 @TA
    2020-06-11 上午11:56
    
    @Luminous 好的，我去看看
LYM @TA
2020-05-15 下午7:19

唔，这篇干货能转载吗qwq
1. Luminous @TA 
  2020-05-15 下午8:04
  
  @LYM 注明出处就可以啦
LYM @TA
2020-05-15 下午7:12

唉。。。。可能是因为咱是校园网的原因感觉没啥差别qwq。现在是CNAME接入。。嫖了云喇叭的railgun节点加速
1. Luminous @TA 
  2020-05-15 下午8:04
  
  @LYM Railgun提升的是CF边缘节点到源站的速度，国内访问慢主要还是国内用户到CF节点慢，回源那点时间占比很小
  1. LYM @TA
    2020-05-16 上午7:34
    
    @Luminous 咱转到法国ovh源站了emmm，总的来说还是加速了不少了emmmm，不过国内cf节点好像只能企业版用？
    1. Luminous @TA 
      2020-05-16 下午3:51
      
      @LYM CF到国内毕竟还凑合，OVH那就是真烂。国内节点要么你从百度云加速加，要么买5000刀的Enterprise，找客服开启国内节点。
chancat @TA
2020-04-05 上午4:05

感谢分享，正需要
1. Luminous @TA 
  2020-04-05 下午1:58
  
  @chancat (｡･ω･｡)ﾉ♡
haojunmei @TA
2020-03-17 上午12:08

目前很多用cf的站都不是自选ip 导致电信联通默认都是洛杉矶机房白天还行晚上慢到爆炸并且我个人对cf不太感兴趣自己工作室网站前段时间备案撤掉了换了阿里海外的cdn 线路都不错国内访问都是日本/新加坡/香港CN2 并且我用的少（没人访问我工作室）我存了十块一年了还没用完
1. Luminous @TA 
  2020-03-18 上午9:20
  
  @haojunmei 流量少还行，流量大的话这些CDN的流量费太贵了，而且功能也没CF多。 CF个人感觉现在就处于一个国内能用就行的状态，差不多就得了。
silmace @TA
2020-03-16 上午1:57

我还想把ip段跑一遍，结果发现几十万个…..cf真有钱
1. Luminous @TA 
  2020-03-16 上午8:13
  
  @silmace 跑到C段就可以，大概2万个(ﾉ ○ Д ○)ﾉ　
  1. silmace @TA
    2020-04-09 上午1:48
    
    @Luminous 批量测ip脚本来啦～就算在同一个子网内不同时间ip质量也不一样 https://blog.stillman.cn/index.php/archives/13/
    1. Luminous @TA 
      2020-04-09 下午2:31
      
      @silmace 感谢大佬补充(￣▽￣)"，已经在文中引用了
Aiden @TA
2020-03-14 下午6:40

已经在我的收藏夹里吃灰了。
另，我用的是CNAME分线路解析配合CF Pro以及Argo路由的加持
现在国内访客速度以及比较快了。
（到晚上一样白给）
sparktour @TA
2020-03-10 上午10:33

补一个从电信cn2 IPv4 去cf的路由 (误
1. 香港： cn2 NTT CF
2.新加坡： cn2 NTT-HK NTT-SG CF
3.阿姆斯特丹 : cn2 伦敦Level3 阿姆斯特丹Level3 CF
4.巴黎: cn2 伦敦Level3 巴黎Level3 CF
5. 圣何塞: cn2 Telia圣何塞 CF
6. 法兰克福: cn2 伦敦Telia 巴黎Telia 法兰克福Telia CF
7.东京/大阪：cn2 NTT-HK NTT-日本 CF

（上面的每一个全天都不怎么堵塞-:）
1. Luminous @TA 
  2020-03-10 上午11:04
  
  @sparktour 毕竟世界加钱可及23333，感谢补充(￣▽￣)"，已经添加到文中了。
  1. sparktour @TA
    2020-03-14 下午11:09
    
    @Luminous 测试用的CN2是学校提供的，但可惜学校给的限速比较低（8Mbps），就算钱加够了也跑不快，不过延迟还是挺稳定且低的（到香港全天12ms）。（CN2效果的一个明显体现就是放假之后同学总会抱怨在学校能加载出来的网站，在家里面就加载不出来了。）
    1. Luminous @TA 
      2020-03-15 上午12:14
      
      @sparktour CN2毕竟单价比163高太多了，1Mbps月费都要80-200的样子……不同省份价格有一些差异
2. Euserv @TA
  2021-05-03 上午10:55
  
  @sparktour 最近在折腾Euserv，本地是上海CN2，发现用香港CF怎么都拉不动，新加坡和美西CF也不太行。看了你的补充，然后去找日本和欧洲的CF，终于起飞了！
Gcod @TA
2020-03-10 上午9:12

总结很到位
1. Luminous @TA 
  2020-03-10 上午10:44
  
  @Gcod 感谢支持(￣▽￣)"
iLPL @TA
2020-03-10 上午12:52

mark
1. Luminous @TA 
  2020-03-10 上午10:44
  
  @iLPL ε=ε=ε=(~￣▽￣)~
蓝皮鼠 @TA
2020-03-08 下午9:35

get到了，吾皇万岁万万岁
1. Luminous @TA 
  2020-03-10 上午10:43
  
  @蓝皮鼠不敢当，不敢当（⊙ｏ⊙）

CZM @TA

2020-03-08 下午7:26

老板，我爬虫呢，我那么大一个爬虫呢。(╯‵□′)╯︵┻━┻
当然，要用shell还可以这样做

#!/bin/bash
czm_nb=0
while(( $czm_nb<=255 ))
do
    curl --connect-timeout 1 -m 2 http://104.16.$czm_nb.86/cdn-cgi/trace | grep "h=\|colo=" >> colo.log
    let "czm_nb++"
done

#!/bin/bash

czm_nb=0

while(( $czm_nb<=255 ))

curl --connect-timeout 1 -m 2 http://104.16.$czm_nb.86/cdn-cgi/trace | grep "h=\|colo=" >> colo.log

let "czm_nb++"

done

Luminous @TA 
2020-03-08 下午10:45

@CZM 大哥太强了| ू•ૅω•́)ᵎᵎᵎ
1. CZM @TA
  2020-03-19 下午8:42
  
  @Luminous 老板才是最强的
平平淡淡、带点小情绪 @TA
2020-03-19 下午5:36

@CZM 不能用啊。。。
1. CZM @TA
  2020-03-19 下午6:09
  
  @平平淡淡、带点小情绪格式乱了，do curl 那里，在do前换行就行

那年雪落 @TA
2020-03-08 下午5:37

学到了
1. Luminous @TA 
  2020-03-19 下午6:56
  
  @那年雪落 (￣▽￣)"，互相交流嘛

1 2 3 Newer »