考虑 1 稳定性 2 便宜优先 3 大流量的话，可以考虑一下欧洲的 OVHCloud 、Hetzner 、netcup 这几家中大厂（）


首先稳定性的话，OVHCloud 和 Hetzner 这两家公司有 20 年以上的历史，netcup 也有 10 年以上的历史；并且它们都在一些区域有自己的数据中心和网络基础设施。

价格方面，按年付月均算，这三家都有日常正价小于 58usd / 12 = 4.83usd 的机器；遇到限时活动的价格会更低；

流量方面，这三家的流量限制基本上在每月几十 TB 到无限。


特点：

Hetzner：更类似于弹性云，可按小时计费；新客户有优惠额度；相对而言较容易注册（可自助 KYC ）；
https://www.hetzner.com/cloud

OVHCloud：数据中心位置分布广泛，分公司较多，每个分站优惠和业务稍有不同。据说爱尔兰分站的独立服务器优惠最大，美国分站较容易注册且可以购买美国地区的服务器；
https://us.ovhcloud.com/vps/
https://www.ovhcloud.com/en-ie/vps/

netcup：虚拟机优惠力度较大（经常有限时活动），新客户可领优惠；账单后付费；注册需提供水电单。
https://www.netcup.com/en
https://www.netcup.com/en/deals


缺点：
考虑到价格和流量，由于地理位置和市场，这几家欧洲厂商的一些服务器到中国内地的延迟可能较高。


注意：
这几家欧洲大厂相较于一些小厂的身份验证较为严格，尤其是对于中国内地的用户。


（利益相关：实际使用过上述公司的服务，链接均无 AFF

同最近遇到这个问题，排查了一下感觉可能是 Google 的权威 DNS 解析器的锅，似乎 Google 的 DNS 服务器对阿里云和中国移动的配置存在错误的“特殊关照”🤔


===

排查思路&流程：

1. 众所周知权威 DNS 解析器一般通过递归解析器的出口 IP / EDNS Client Subnet 判断访客地理位置，于是我们可以找一个 dnslog 服务来抓一下阿里云递归解析器的出口 IP 。用 itdog 的拨测工具查询一下随机分配的域名，可以抓到以下 IP：
https://i.imgur.com/qayQrcT.png


2. 这个 dnslog 似乎不能翻页（），就拿图中测试发现有问题的山西太原移动为例
https://i.imgur.com/OCvZf5J.png

用它的 183.201.217.0/24 作为 Client Subnet ，用国内移动的网络对 ns1.google.com 直接发起查询：
dig @ns1.google.com connectivitycheck.gstatic.com A +subnet=183.201.217.0/24 +norec
https://i.imgur.com/KF59hjq.png

ns1.google.com 返回了美国 Google 的 142 开头的 IP 。这样直接请求的过程完全没经过阿里的服务器处理，暂时可以排除 alidns 的嫌疑了。


3. 起一个 Cloudshell 从阿里云的服务器上请求一次，还是同样的结果。
https://i.imgur.com/QOXWUi6.png

但是把 EDNS 里的客户端子网换成一个“干净的 IP 段”就能得到正确响应，例如我们这里用 sx.10086.cn 的 IP 地址试一下，可以看到 Google 返回了国内的 CDN：
dig @ns1.google.com connectivitycheck.gstatic.com A +subnet=183.203.36.0/24 +norec
https://i.imgur.com/A335Sjc.png
（其它国内 IP 也行，哪怕 1.14.5.14/32 也可以
（ dig @ns1.google.com connectivitycheck.gstatic.com A +subnet=1.14.5.14/32 +norec


4. 更神奇的来了，在腾讯云上请求 ns1.google.com 时，即使 EDNS Client Subnet 里填写“不干净的 IP”也能得到正确结果（这里换成电信/联通应该也可以，实测联通没问题）：
https://i.imgur.com/5pSPgba.png


=====

总结：
- 对于此类有国内 CDN 加速的 Google 服务，Google 的权威 DNS 服务器在遇到“阿里 DNS 查询上游所用的部分中国移动出口 IP 地址”时，会错误地返回国际 CDN IP 。

- 在内地使用腾讯云/中国联通/中国电信的 IP 或网络对 Google 的 DNS 服务器发起查询似乎不受影响。

- 该问题理论上与劫持无关，因为使用海外测试服务器可以得到与境内阿里云/中国移动类似的结果。


======

解决方法：

如果要继续使用阿里 DNS ，可以对客户端进行配置，为 AliDNS 配置一个 EDNS Client Subnet （阿里的公共递归 DNS 会转发 Client Subnet ）。

mihomo 的配置方法见如下文档：
https://wiki.metacubex.one/config/dns/#_1

sing-box 的配置方法见如下文档：
https://sing-box.sagernet.org/migration/#__tabbed_1_13
https://sing-box.sagernet.org/zh/configuration/dns/rule_action/#client_subnet

（若要兼顾就近 CDN 调度与隐私，EDNS Client Subnet 的值一般可以随便填写一个同市/省会的 IP

测试了 Qwen 最新的 max 和 coder ，把 top_p 拉到最低、temperature 拉到最高也复现不了这个问题
https://i.imgur.com/r7DPfyE.png
https://i.imgur.com/am2ob0L.png
这种情况明显是受其它提示词干扰造成的

MediaWiki 的大多数界面文本都由“系统消息”控制：
https://www.mediawiki.org/wiki/Help:System_message

例如下面的这个特殊页面可以显示某站点的所有系统消息：
https://www.mediawiki.org/wiki/Special:AllMessages

对于你的问题，要修改其显示的文本，可以使用：
https://www.mediawiki.org/wiki/MediaWiki:Vector-toc-beginning
https://www.mediawiki.org/wiki/MediaWiki:Vector-toc-beginning/zh
https://www.mediawiki.org/wiki/MediaWiki:Vector-toc-beginning/zh-cn

若要阻止这个文本显示在页面上显示，可行的一个办法也许是编辑 MediaWiki:Vector.css ，这样可以为 Vector 主题添加额外的 CSS 样式（例如给这个`<div class="vector-toc-text">Beginning</div>`加一个'display: none;'），具体位置例如：
https://en.wikipedia.org/wiki/MediaWiki:Vector.css

@xqzr 你才是 AI 吧，你倒是给我说说这哪里像 AIGC 了
https://i.imgur.com/FPd3rWB.png
==================

你家 LLM 和也我一样喜欢偷懒括号只打一半+混用大小写🤔？并不是长文+提供解释+Markdown 就是 AI 。

（你可以试一下把帖子连带 19 楼前的内容作为 context 扔给 LLM 看看 AI 的回复是什么样的，我猜它们多半逃不过“总分总”格式 + 有序列表 + 礼貌套话。


我说话风格就这样哈，欢迎点我头像看历史回复。像不像 AI 无所谓，能有理有据地理性提供参考&解决问题就行。

个人感觉可能不太行🤔，原因如下：


合规方面：

如楼上所述，服务器扔国内的话合规方面有很高门槛。大家耳熟能详的国内递归 DNS 解析器一般背后都是大厂/老牌/顶尖高校，个人搭设相关服务有喝茶风险。
（例如你的服务器能不能解析轮子网站?）（例如网赌/成人 app/黑产把你的 DNS 集成进去…）


维护难度/成本方面：

- 服务器在国外的话明文 TCP/UDP 会无法正常使用（阻断/抢答），然而面向大陆用户的服务当然离不开访问速度或者可靠性的问题。


- 速度方面：
服务器放国外的话可能会遇到晚高峰网络拥塞、UDP 被 QoS 严重的问题（尤其是 DoQ/DoH3 ，可能变得比 TCP+TLS 还卡）。
并且一些网站/服务的权威 DNS 解析器可能并不支持 EDNS Client Subnet ，从单个地域向这类权威解析器发起请求时返回的 CDN IP 地址可能离客户的出口很远。同样地，国内服务的 CDN 就近解析也是一大问题。


- 可靠性方面：
以及如果有脚本小子/找茬的人打过来了，我们的服务能不能有效防御 L4/L7 的 DDoS 攻击？要不要上 Anycast ，还是直接用域名做负载均衡？
并且监听像 853 之类的端口被抓到很容易被墙，换域名/ip 也是成本。

这些都是很现实的，可能需要砸不少钱、不少精力去解决的问题。（尤其是可靠性方面，因为 DNS 服务器挂掉的话设备可能在短时间内用起来就像断网了一样，用户感知非常显著。


市场/用户付费意愿方面：

- 优势上，相比传统方案，我们的服务能解决用户的哪些痛点？现代代理软件在 DNS 规则分流/抗污染/防泄露上已经有了相对成熟、高效的、甚至能开箱即用的机制。对于非代理软件的场景，我们的服务是否能在客户无需配置分流的情况下让用户花钱买省心？

- 相较于同类 ToC 竞品（例如 Adguard DNS 、NextDNS ），我们的服务可能会缺少广告/跟踪器拦截、钓鱼网站/恶意软件屏蔽、上网保护（屏蔽成人内容）以及完备的控制面板、自助注册登录付费开通等优势；相较于同类 ToB 竞品，节点数量、APP SDK 接入、可用性保证等优势也很难追上。

- 价格上，解决前面提到的痛点需要巨大成本（包括精力与兴趣）

- 隐私方面，用户在把高度私密的 APP 使用记录/网站访问记录交给小厂时必然会有不小的顾虑。同时你是不是得需要考虑准备使用什么方式收款？


楼主可以根据具体市场需求考虑一下这些问题。

没遇到过这种情况（我这边一直使用 WARP 的 IPv6 出口，持续使用两个付费账号直到被封都没有出现过降级）

如果使用的是 WARP 的 v4 出口的话可以试一下调整代理软件的配置，用 IPv6 出口访问 ChatGPT 。IPv6 由于地址成本更低、IP 数量更多、单个地址下使用人数更少、IP 风险数据/IP 威胁数据量更少相对不那么容易被风控。
https://i.imgur.com/x749siO.png
（不过如果还是不行的话可能就需要加钱换其它提供商的 IP 了）

================

将 Cloudflare WARP 配置为代理出口一般是为了：
1. 防止 VPS 的 IP 地址泄露
2. 为单栈网络的服务器添加双栈支持
3. 洗白部分 IP 地址评级过低的高风险数据中心 IP
4. 改善代理使用过程中到 Cloudflare 网站的速度

================

对于楼主提到的其它问题：

> 目前我知道市面上有一些 sh 脚本能检测 IP 的质量，但是感觉结果并不准确，明明检测出来是 ChatGPT 是可用的，结果实际还是出现了降智的情况

对于检测 IP 质量的 shell 脚本（“流媒体解锁测试”）里的“ChatGPT 解锁”这一检测项目而言，它测的其实是“被测 IP 会不会触发 OpenAI 在 Cloudflare 上配置的某个防火墙规则”，这个规则仅针对 IP 地址的所在地区和 ASN 。

当初 GPT-4 时期 OpenAI 把这个规则设置得很严格，不少数据中心 IP 都会被拦截，而如今 OpenAI 已经放开了限制，大部分代理落地常用的数据中心 IP 都不会被拦截了。


> 一些测 PoW 的插件也是提示 IP 纯净，没有被降智，但是确确实实就是被降智了

这些插件或 UserScript 的原理是检查`/backend-api/sentinel/chat-requirements`或`/backend-anon/sentinel/chat-requirements`的返回结果。该检测方法大概是去年 11 月初左右开始流行的，现在很可能不一定管用了。并且这个 API 返回的结果还受浏览器环境影响

（例子：在我的环境中，相同 IP 下使用 Chrome 可以免登录访问 ChatGPT ，Firefox 则不可以）
https://i.imgur.com/2c6Vao1.png


> 如果不纯的话有没有什么别的办法更换另一个纯一点的出口 IP 呢

应该是不能的。虽然更改接入地区或切换 WARP 套餐可以影响出口 IP 范围，但是这样也不能确保换到的 IP 就是使用人数较少的/风险分数较低的。


> 我原先看网上那么多推荐套 WARP 的文章还以为就是可以解决 IP 不干净的问题，没想到反而还加剧降智了。

套 WARP 一般是绕过某些网站/服务对数据中心 IP 的限制。例如 WARP 可以解锁 Imgurl 图床/无需登录直接访问 Reddit ，而不少中低端机场提供的 IP 不可以。

因为一般来自像 VPS/ECS 这类服务数据中心的流量非常可能是机器或者自动程序发出的（毕竟爬虫之类的程序可以直接跑在云厂商的基础设施上面）。但由于 VPN 在海外往往以“隐私保护工具”作为卖点，若某部分 IP 地址被专用于 WARP 这样的 VPN 服务，那么各种网站在限制甚至封禁这些 IP 的时候就得更加谨慎地掂量一下请求与流量背后是不是无辜的人类用户。

另外苹果 iCloud Private Relay 的出口 IP 也是 Cloudflare 提供的（ https://blog.cloudflare.com/icloud-private-relay/#understanding-traffic-flows
某些网站可能会因为偷懒等各种原因一并放行消费级 WARP 用户和 Cloudflare One 的 VPN IP 以防误伤无辜的人类用户。

应该是写后端的时候因为偷懒/没睡醒/水平太菜，用了`strings.HasPrefix()`之类的东西来判断图片地址是否合法。

`i0.hdslb.com`这个字符串放中间或末尾都会触发“图片 bucket 错误”的报错，但是只要图片 URL 的域名部分的开头为`i0.hdslb.com`都可以通过校验。这导致攻击者可以通过修改“发布动态”时向服务器提交的 payload ，以此将图片 URL 指向自己的服务器。
https://i.imgur.com/UMCUERS.png

由于客户端/浏览器在请求时携带的信息较少，攻击者很难将获取到的泄露信息关联到具体的用户或账号。

==============

对于用户的风险： 除 IP 泄露风险外，使用较旧浏览器的用户和 b 站客户端用户还有设备型号泄露的风险；加之客户端会跟随 30x 状态码进行跳转，使用按量计费方式上网的用户可能有流量被浪费的风险。
（其它平台的类似攻击案例：某知名即时通讯 APP 中，攻击者可以通过修改 XML 结构化消息中的图片的`cover`属性并在群聊中发送构造的特殊消息，以此获取“看到消息的群成员”的 IP 地址并统计群内活跃人数）

对于平台的风险： 用户可以在动态发布后替换图片，发布时间戳将不再可信。少数用户可能利用此类特性隐藏编辑痕迹，以此达到炒作或抵赖的效果。
（其它平台的炒作案例：在高考答题期间发表任意带图内容，考试结束后将图片替换为试卷图片，谎称“试题在考试期间就已泄露”以骗取关注与热度）

类似帖子： https://www.v2ex.com/t/1108461

顺便补充一个方法：除了发 email 和找 https://telegram.org/support 之外，还可以去 Twitter 上私信 https://twitter.com/smstelegram 这个账号

@doraemon0711 #10

我这边测试是可以使用的🤔，至少在 Windows 11 23H2 （ 22631.5126 ）上测试无法复现这个问题。

这个注册表项只是让 Windows 资源管理器(explorer.exe)不要注册 Win + V 这个快捷键，它没有阻止其它应用程序注册 Win + V 这个快捷键

https://i.imgur.com/Zwt2ayK.png
https://i.imgur.com/MLKGMBM.png

可能的坑：
1. 由于我之前一直在使用 Windows 内置的剪贴板管理器，我在复现这个问题的时候注意到 Ditto 第一次注册快捷键的时候的确会提示注册失败(Error Registering DittoHotKey)，但是重启资源管理器后再重启 Ditto 并设置快捷键问题即会自动消失
2. 打开 Ditto 的选项界面并切换到“键盘快捷键”选项卡时会无法触发快捷键，需要先关闭设置窗口才能使用

@mxdyeah #10
应该是运营商 DNS 的问题，因为 chat.avatar.ext.hp.com 在失效前解析的最后一个 IP 就是 35.165.19.99
（并且现在无论是这个 aws elb 域名还是其对应的 IP 地址都无法提供服务了）
https://i.imgur.com/4A6hRHq.png

应该是程序的重连重试机制没有写好导致的问题：

这个域名如今在递归解析器和权威解析器上都返回 NXDOMAIN （没解析），查询 chat.avatar.ext.hp.com 的解析历史发现它的解析在 2023-05-18 就停了，而写死的程序显然没法知道外部服务的更变，只能一直重试…

https://i.imgur.com/7sWa0j3.png
https://i.imgur.com/KoOa26I.png

参考这篇回答 https://superuser.com/questions/1439819/disabling-winv-on-windows

总结：
1. win+r 执行
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced /v DisabledHotkeys /t REG_SZ /d V
2. 重启 Windows 资源管理器或重启操作系统

======
这个问题其实可以快速用搜索引擎找到答案，Google 搜索词：windows disable clipboard history keyboard shortcut

是的，一般就是为了防止攻击；有的网站甚至会判断浏览器语言(accept-language)来拦截请求。

同遇到过这个问题，猜测是邮箱不一致造成的；提供一个玄学办法，不保证管用：


0. 根据 GitHub Education 申请时的一些条件，这边假设你已经在 Github 设置了能用的 Public email 。
最好不要挂代理，如果可以的话用学校附近的 IP 访问

1. 打开微软账户的管理页面
https://account.live.com/names/Manage
点“添加电子邮件”把 Github 的 Public Email 所用的这个邮箱添加到微软账户，然后回到这个页面再点“设置为主要”把它设置为“主要别名”
https://i.imgur.com/EjDYDVB.png

2. 这个时候再登录 Azure 看一下邮箱有没有变成我们刚刚改的邮箱。可能有缓存，如果没有变需要等一会 / 多试几次登出+登录。
https://i.imgur.com/tqS7std.png

（可以看到 我这边为了演示改了邮箱之后微软的玄学系统直接把我的账号卡出了影分身，甚至直接把我之前注册过的的 Azure for students 卡没了😡）
（但是我这边把邮箱改回去之后就能恢复，通过这点我觉得 Azure for students 的验证机制可能的确和邮箱强相关）

3. 如果 Github 的邮箱和微软账户的“主要别名”能保持一致的话（或者确认缓存更新了）则可以继续：
在无痕模式 / InPrivate 里打开 https://signup.azure.com/studentverification?offerType=1 ，选下面的“使用 GitHub 登录”。

理论上到了这里就不会再出现之前的问题了（由于我这里只能执行续期操作没有办法继续演示了😿）
https://i.imgur.com/ni0zyQH.png

==========
这个方法是“玄学”方法的原因是：
1. 我这边用的是资料验证而非邮箱验证，所以不知道这个方法是否对教育邮箱验证有用
2. 看上面的回复甚至微软他们自己也不知道这个问题是怎么来的

希望有所帮助（