(本文是个乌龙)
这个问题来自于p师傅在小密圈里的讨论https://wx.zsxq.com/dweb/#/index/2212251881，但是好像没有人进行研究，当时我稍微看了一下，得出的结论基本和p师傅想的一致:1.问题源于安全层 2.对不同来源ip有不同策略。

问题定位

p师傅给出的问题url为https://www.threatcrowd.org/searchApi/v2/domain/report/?domain=baidu.com。
先把上面得出的结论给确认下来。我这里使用了两台服务器，一台是谷歌美国，一台是腾讯云上海，两台都装上v2ray，然后使用sstap来开启全局流量，加上当前本地是在杭州移动教育网，一共有三个出口ip。
经过测试，谷歌美国ip是所有请求都不拦截的，腾讯云上海是全部拦截，而本地是chrome和curl被拦截，其他正常。所有请求稳定复现。
鉴于使用的是v2ray将流量进行转发，应该可以认为是做到了只有ip不同，没有其他更多影响因素。
以下是测试过程。

本地环境

Windows10 1803
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
httpie 0.9.9

控制变量

首先先控制变量，把发出的http请求尽量都控制成一样的(由于工具不同，完全保持一致还是有点麻烦的，比如不同header的顺序)，且确定目标的ip为同一个ip，设定为我本地解析来的104.31.0.183，http参数以我当前的chrome为参照，另外可以确定的是，目标启用了http2。
返回内容会经过压缩，只要看响应码就可以了，200为正常，503为拦截。

chrome

:authority: www.threatcrowd.org
:method: GET
:path: /searchApi/v2/domain/report/?domain=baidu.com
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
dnt: 1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

curl

curl -iv "https://www.threatcrowd.org/searchApi/v2/domain/report/?domain=baidu.com" -H "method: GET" -H "authority: www.threatcrowd.org" -H "scheme: https" -H "path: /searchApi/v2/domain/report/?domain=baidu.com" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" -H "dnt: 1" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "accept-encoding: gzip, deflate, br" -H "accept-language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7"

powershell

Invoke-WebRequest -Uri "https://www.threatcrowd.org/searchApi/v2/domain/report/?domain=baidu.com" -Headers @{"method"="GET"; "authority"="www.threatcrowd.org"; "scheme"="https"; "path"="/searchApi/v2/domain/report/?domain=baidu.com"; "upgrade-insecure-requests"="1"; "user-agent"="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"; "dnt"="1"; "accept"="text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"; "accept-encoding"="gzip, deflate, br"; "accept-language"="zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7"}

requests

import requests
headers = {
    'authority': 'www.threatcrowd.org',
    "accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
    "accept-encoding":"gzip, deflate, br",
    "accept-language":"zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7",
    "dnt":"1",
    "upgrade-insecure-requests":"1",
    "user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
}
url = 'https://www.threatcrowd.org/searchApi/v2/domain/report/?domain=baidu.com'

r = requests.get(url, headers=headers)

httpie

http https://www.threatcrowd.org/searchApi/v2/domain/report/?domain=baidu.com "authority":"www.threatcrowd.org" "accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" "accept-encoding":"gzip, deflate, br" "accept-language":"zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7" "dnt":"1" "upgrade-insecure-requests":"1" "user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"

不同ip测试

这里没有贴图，如果有人愿意复现，应该可以得到一样的结果。
下面谷歌美国和腾讯云上海两个截然不同的情况说明了一件事:cloudflare有多重策略。
至少可以确定其中一种是对ip进行强制拦截和完全信任，而杭州移动教育网的情况说明了另一种未知策略的存在，且该策略优先级低于ip策略。该策略的具体内容应该在http应用层之下(因为修改http请求后，结果不变)，目前认为是安全层。p师傅认为可能与这篇文章所述类似。

本机

工具	http状态
chrome	503
curl	503
powershell	200
requests	200
httpie	200

谷歌美国

工具	http状态
chrome	200
curl	200
powershell	200
requests	200
httpie	200

腾讯云上海

工具	http状态
chrome	503
curl	503
powershell	503
requests	503
httpie	503

问题分析

分析流量

于是用wireshark抓了五个工具发出的数据包。
突然发现httpie和chrome拿到的目标ip不一样……然后发现其实是httpie默认走了系统代理，也就是翻墙了……

好的。

再见。

完。