是每次使用 NewBing 前都要发这段英文吗？

我只知道个大概，可能并不准确。

1. 以前 运营商 是可以精确识别到 BT 协议的，并限制 BT 速度（甚至干扰），后来有人搞了个 BT 协议加密，陆陆续续升级了好几代了，不过尴尬的是不同 BT 客户端支持的程度不一样，而且很多客户端都是默认关闭该功能的，而协议加密是需要双方支持且开启的。
确实这些年好像加密协议没啥更新动静了，主要还是因为不像互联网协议一样，没有统一的组织牵头制定标准什么的，各客户端支持与否完全由开发者自身意愿决定，所以就算你写个更好的加密协议，但没其他客户端用的话，就只能在自己的客户端圈子里内部使用了，然后慢慢的大家都成 “孤岛” 了。

2. 协议加密后应该是看不到的吧。。。（这我也没法验证
不过可以通过其他方式查看你下载了什么 BT 资源，例如该网站：
iknowwhatyoudownload. com/en/peer/
因为你通过 Peer 、DHT 、Tracker 获取 /链接其他用户时，也就因此而暴露了你要下载的资源内容。

@OK1writer 你可以如楼上所说清理一下 cookie 。
不过，虽然我觉得大家应该都明白，但还是想问一下：我步骤里写的必应域名中的空格你去掉了没？。。

@OK1writer 不清楚你是怎么配置的，可能是哪里没搞好吧，我这边是完全没问题（从 2 月 8 日到现在）。

运营商一般都会限制家宽的 80 443 端口，这好像都算常识了吧。。。

你这种情况是正常的，你发送消息到网站，网站也收到并回复你了。
但在你发送消息后，旁路的设备监测到了并伪造了 RESET 响应返回给你，而因为旁路设备离你更近，因此会比目标网站的正常回应更快的返回给你，你的浏览器收到后就报错 NET_CONNECTION_RESET 了，并会忽略后续发来的正确响应（如果你收到了的话）。

当然，这种情况是你与服务器之间 IP 通顺的情况下，如果是 IP/端口 被封了，那么就是报错超时了。

和 DNS 污染（劫持）原理是一样的，只不过一个是针对 DNS 一个是针对 HTTP （或者说域名）。

一直就有啊。。。从当初预约候补的时候我就这样干了。

浏览器安装 Header Editor 扩展。

添加规则将 www. bing. com 的 x-forwarded-for 设置为任意国外 IP 就能避免跳转至国内版必应。

另外，将 www. bing. com 的 user-agent 设置为 Edge 浏览器的即可在 Chrome 等浏览器上使用：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Edg/110.0.1587.57

另外，需要注意的是，Bing 的 国家区域 设置不能是中国，语言的话可以是中文。

如果属实，这显然是犯 罪了吧，但根据以往案例来看，最终都是不了了之，顶多把程序员拉去背锅。。。

话说，你们 Wise 提现到国内是提现到 银行卡，还是提现到 支付宝 ？

我记得去年开始提现到 支付宝 很容易触发要求申报来源？很久没用了不知道现在还会不会了。。。

确实，刚刚收到了邮件（从 8 号到现在，那些步骤我也都做了），不过前段时间大家都说 NewBing 阉割了？

@montoyaf
我测试是和以前差不多，建立 HTTPS 链接后，一开始会成功，但成功几次后，后续的都会超时（因为 443 端口超时了），不过可能是刚刚恢复 SNI 阻断的原因，感觉比以前测试的时候更容易触发一点。。

@montoyaf 你来晚了，中午又刚给封上了，总共放风了 3.5 天。。。

我擦，我测试发现好像又开始 SNI 干扰了，可以轻松复现问题，又是单独 443 端口超时 3 分钟。。。

大家再测试看看，是个别现象还是又全部都又回来了？

我早上测试还正常了，刚才（ 12 点）又不行了，难道开放 3 天半又 G 了？。。。

@SteveRogers #72
嗯，其实 Steam 商店、Github 在早年间也是被封过（虽然比较短暂），后来解封了。

Github 是 2013 年 1 月 20 日左右被完全封锁，印象中是李开复带头 “搞事”，然后没过几天就解封了。
Steam 商店是 2014 年 10 月 23 日左右被完全封锁，然后没过多长时间也解封了。

后续这些年也有不少网站被封后，过段时间又解封的情况出现（有的被解封后就主动屏蔽国内了）。

@kyor0 #50
一般来说如果是乌龙事件的话，应该几天内就会发现并处理（已经恢复最少三天了），如果没处理要么就是真的解封了，要么就是有什么原因导致被迫暂时解封开放一段时间。

不过，我觉得应该要等下个月开完会后，如果还能正常访问，那么就不用担心了（至少短时间内）~
毕竟当初 Github 就是在 2021 年 3 月 开会 前几天被封的。。。

@xuwuyibing #52
Steam 社区域名是完全被墙了，我昨天也顺便测试了，指定正确 IP 也依然会被重置链接无法访问。。。

@LnTrx #54
Cloudflare CDN IPv4 我是去年遇到了 IPv4 干扰问题（就是如前面所说类似于 SNI 干扰，但针对的是 IP ），同样去年我这里也遇到了 Fastly CDN IPv4 干扰问题（和 Cloudflare 差不多，都是只针对 IPv4 ）。
至于 AWS Cloudfront CDN ，我倒是没遇到类似情况，可能是因为我平时用的较少。

@jayfire2 2020 年 7 月宣布大力扶持国内开源代码托管平台，2021 年 3 月封了 Github ，结果两年过去了，扶持了个寂寞，各种大坑（特别是审查方面的）成功劝退了很多人，即使被拦着也无法阻挡大家依然把 Github 视为开源社区的第一选择，再加上这些年 AI 火热，特别最近 ChatGPT 又引发了一阵火热。

如果此次突然解封不是乌龙的话，那么我估计多少和这些有点关系~

@OldCarMan 我设置了默认浏览器，也下载了 Bing APP ，并且连续用了几天（那什么积分我也整了好几百），但从 8 号到现在九天过去了依然没动静，气得我把 Bing APP 删了，默认浏览器也切换回 Chrome 了。。。

@bollld607 我在其他网站看到有人提到了 Cloudflare CDN 的 IPv4 阻断情况消失了，我也尝试直连那些套了 Cloudflare CDN 网站，持续了几个小时，确实没有发现以前很容易复现的 IPv4 阻断情况了：
https://github.com/XIU2/CloudflareSpeedTest/issues/217

另外，虽然 Cloudflare CDN 是被 IP 干扰（针对的是 IP ，不在乎是什么域名），但和 SNI 干扰（针对的是域名，不在乎 IP 是什么）还是有点相似的，甚至可以说本质是一样的。
比如都是间歇性的，而非完全阻断（区别于 SNI 阻断、IP 阻断），超时也都是 3 分钟整，触发后 TCP 443 超时但 TCP 80 端口、ICMP 通顺等等。

所以我猜测，蔷似乎是把 SNI 干扰、IP 干扰都给取消了。。。