Add expectedResponseCode to BurstObservatory

[yuhan6665]

{
"destination": "https://connectivitycheck.gstatic.com/generate_204",
"expectedResponseCode ": [ 204 ],
"interval": "1h",
"sampling": 3,
"timeout": "30s"
}

[Fangliding]

能麻烦看一下 #4054 吗 这个从instance里取出观测器的操作我觉得应该不会吃那么多资源才对()

[yuhan6665]

能麻烦看一下 #4054 吗 这个从instance里取出观测器的操作我觉得应该不会吃那么多资源才对()

好的 我有空看下

[RPRX]

明天发 REALITY NFT 和新版，这个 PR 要赶上吗

[gydchenxiao]

明天发 REALITY NFT 和新版，这个 PR 要赶上吗
R佬，新出的REALITY的nft，会很贵吗🥲，我可不可以直接发10u拿一个空投呀，谢谢🥲。有提前预售啥的，谢谢。😢

[RPRX]

R佬，新出的REALITY的nft，会很贵吗🥲，我可不可以直接发10u拿一个空投呀，谢谢🥲。有提前预售啥的，谢谢。😢

本来想发一万个但感觉太多了，预计发一千个，前一百个 0.01 ETH，35U，没赶上第一波 Project X NFT 的要抓住这次机会了

[gydchenxiao]

R佬，新出的REALITY的nft，会很贵吗🥲，我可不可以直接发10u拿一个空投呀，谢谢🥲。有提前预售啥的，谢谢。😢

本来想发一万个但感觉太多了，预计发一千个，前一百个 0.01 ETH，35U，没赶上第一波 Project X NFT 的要抓住这次机会了
唉🥲，有点贵呀，那发3000个呢，我

[RPRX]

唉🥲，有点贵呀，那发3000个呢，我

只能说抢到首发就是纯捡漏，Project X NFT 首发价 0.033 ETH，现价 0.18 ETH，很多人一下买两个就成了资产而不是纯消费

[RPRX]

其实对于 #3114 (comment) 我是有点没看懂，这 HTTPS 的 204 咋还会被劫持为 200？@FightingForFun @yuhan6665

@Fangliding 元 fang 你怎么看

[RPRX]

还有 XHTTP 的文档又需要更新了

[Fangliding]

这句话的意思大概是 《如果》 xray收到了来自根目录的那个谷歌搜索的界面 xray仍会认为连接成功 即使它的回复是不正确的 所以加一个204检查 类似的行为还能拓展到期望的响应头或者响应体巴拉巴拉的
顺便xray的黑洞能自己定义一个403的响应 可以把常用的http真延迟测试链接劫持过去( http://cp.coudflare.com 什么的) 绝大多数客户端的真连接延迟检测都是不检查

[RPRX]

《如果》 xray收到了来自根目录的那个谷歌搜索的界面

所以为什么谷歌会对 generate_204 响应根目录

[RPRX]

《如果》 xray收到了来自根目录的那个谷歌搜索的界面

所以为什么谷歌会对 generate_204 响应根目录

是因为要求登录吗，然后这个节点就被认为是 unsuitable？

[RPRX]

我想了下，我是见过谷歌拒绝某些 IP 的那个页面，没想到它对 generate_204 也会这样

但是 https://connectivitycheck.gstatic.com/generate_204 这个链接应该不会，默认加不加期待 204 应该没区别

所以 @FightingForFun 是用 https://www.google.com/generate_204 来判断谷歌可用性，我觉得确实可以扩展到期望的响应头等

[yuhan6665]

应该不是谷歌的问题 我理解是服务端有什么 redirect 比如用户没交费就全部转发到登录页面 类似飞机场 wifi 那种
还有就是有些政府的审查方式不是黑洞 而是返回一个页面 比如美国的 seized domain

[RPRX]

应该不是谷歌的问题 我理解是服务端有什么 redirect 比如用户没交费就全部转发到登录页面 类似_飞_机场 wifi 那种 还有就是有些政府的审查方式不是黑洞 而是返回一个页面 比如美国的 seized domain

按我的理解 HTTPS 被 redirect 不应该出错吗

[o0HalfLife0o]

应该不是谷歌的问题 我理解是服务端有什么 redirect 比如用户没交费就全部转发到登录页面 类似_飞_机场 wifi 那种 还有就是有些政府的审查方式不是黑洞 而是返回一个页面 比如美国的 seized domain

按我的理解 HTTPS 被 redirect 不应该出错吗

大概是类似这样，cf worker部署vless，检测proxyIP时，有的ip实际不可用，但并不会超时或直接返回404，也不是所有地址都不可用，而是仅对比如/cdn-cgi/trace这样的正常，其他地址则返回200、301、403什么的，让你误以为正常