维基百科

帮助讨论:如何访问维基百科/存档2

< Help talk:如何访问维基百科
Space Timee在话题“昨天2620:0:861:ed1a::1和2620:0:863:ed1a::1都被屏蔽了”中的最新留言：2年前

各位觉得维基百科中文版政策是不是该宽松些？

最新留言：在8年前发布107条留言22人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2016年9月16日 (五) 00:42 (UTC)。

如题。维基百科中文版在大陆已被封锁，诸位可能有些居住在大陆之外吧？
可是我们大陆用户不可能每天都花大功夫破网，结果却发现ip被封禁！！！而且破网的话网速必然会慢，等待加载半天却发现ip被封禁！！！好痛苦的感觉！！
我几乎没有什么编辑，但我衷心喜爱维基百科。看着被封杀的维基百科一天天堕落了不甘心，哎！
维基百科能不能给大陆用户一点方便，解禁一些ip?毕竟很少人买VPN用来泡维基，我想我们都是看到了随手改一改啊
要么我，，也去申请ip解禁可以么？ 重点是都被封禁了，想尽可能免费来访问也不容易，实在不想反复寻找ip段外的破网软件了！这么麻烦谁会来维基百科呢？这么麻烦谁会编辑呢？

手机速打，不胜其烦。我可能有些过激，还望各位多多包涵！

Talkative Sun 2016年8月21日 (日) 09:23 (UTC)

长者说过：闷声大发财，这是最好的。其实也是有些没有被封的代理的发现了就拿去续一秒。对了某维基QQ群不是有管理员发IPBE吗。--20160821ax（留言） 2016年8月21日 (日) 11:03 (UTC)


比较

  1. 各位觉得维基百科中文版政策是不是该宽松些？
  2. 各位觉得中国网络过滤机制是不是该对维基百科中文版宽松些？

我的答案：

  1. 没必要，且维基百科中文社群已有Wikipedia:IP封禁例外的作法，是不是对中国网络过滤机制受惠/害地区有宽松些呢？好像有。
  2. 有必要，中国网络环境和生态已不是十年前，应该有自信面对 维基百科中文版 的内容、实践、及生态。

--❦‽研究及来源 hanteng✉ 2016年8月22日 (一) 09:12 (UTC)

反对封禁维基，但反对“中国网络环境和生态已不是十年前”一句，我觉得中国那群键盘侠从没消停过，网民素质也有待提高。--晴空·和岩 讨论页·反互煮·协作计划 2016年8月22日 (一) 10:20 (UTC)
不但是没有消停，前段时间是跟着共青团微博的节奏变得越来越有趣。甚至…… [2] ——Artoria2e5编 保持页面整洁，直接ping我回复。 2016年8月22日 (一) 10:35 (UTC)
没错，本来有一种网民就叫中国网民嘛……--№.N（留言） 2016年8月22日 (一) 11:06 (UTC)
1. 未登录用户甲打开VipABC，试图清空页面，鼠标点击编辑。打开页面，点击文本框，点击鼠标右键，全选，点击右键，删除，保存更改。一共按了7个键。
2. 未登录用户乙打开VipABC，试图粘贴受到版权保护的文字，鼠标点击编辑。打开页面，点击文本框，点击右键，粘贴，保存更改。至少按了5个键。
3. 未登录用户丙，添加[[Category:VIPABC]]这种正常的分类，至少19个键。
6位验证码对于用户甲工作量大约增加1倍，用户乙也是如此，用户丙的工作量只增加了6/19×100 = 32 %。可见验证码对不同用户效果不一。—John Doe 120（talk） 2016年9月5日 (一) 14:09 (UTC)

反驳

  • 1、我反对将维基百科精英化：我想，维基百科需要的（存在的意义也）是人人能编辑，人人可编辑。正如上方Antigng所言，中文维基百科不是港澳台地区专用维基百科！
  • 2、@Hanteng：您所说的第二项似乎有失偏颇。大陆的封网力度近期还是比较放松的。例如：
    • 敏感字封锁、直接RESET、HTTPS封锁都取消了。而我相信HOSTS封锁至少是比较弱智的。
  • 3、最明显的是：这种情况肯定不会持续很久。有能力封锁关键字却没能力封锁DNS吗？


我想请求的是：对某些常用代理软件的ip段适当放宽。“精英”们可以24H泡在中文维基中，一般人更多的则是点到就看看，顺手编辑改错。如果为了避免破坏拒绝大陆用户的请求，那也只能平静平静了。看看就好，不许说话。这种风格不正是某种意义上的意识形态思维么？

Talkative Sun 2016年8月22日 (一) 11:46 (UTC)

不要把别人的错误强加在自己头上。同样地，不要把GFW的错误加在维基百科头上。“对某些常用代理软件的ip段适当放宽”，中文维基百科担当不起。--Antigng（留言） 2016年8月22日 (一) 12:01 (UTC)

(－)反对：上网在许多国家已属众多基本人权之一。世界近200个国家中的至少195个、与约290个维基语种中的大概285种的不计其数编者经过15年所形成的反破坏共识、常识、规范，当已属最低必要手段。中国政权干的事是贵国人长期纵容所造成，各国造业各国担，维基百科与自由民主制国家完全没必要承担极少数个别独裁政权为巩固一党专制所转嫁的管理成本。维基从没欠过中国或中国人什么。冤有头，债有主，别老是搞错对象！--WildCursive（留言） 2016年8月23日 (二) 00:21 (UTC)

  • @Wildcursive：您是想表达什么？台湾地区没有任何网络审查吗？还是歧视我们这些中国人？中文维基百科的运行，难道只是借助于港、澳，台湾地区的朋友就可以了吗？您可以保留您的意见，但请您不要将维基百科用来宣传个人观点。难以理解。只是一个讨论而已，我并没有渴求什么。例如将封禁ip段设置验证码编辑行不行呢？Talkative Sun 2016年8月23日 (二) 05:09 (UTC)
    • @Talkativesun：在台湾的国境内，任何人要逛什么公开网络都是主权在民之台湾国民的个人自由，美国人、日本人、德国人能逛的，台湾人自然都能逛；朝鲜、中国、老挝等独裁国家未封的，台湾人当然也能逛，但可能没兴趣逛。从无任何台湾的中央或地方政府机关有权或曾有权去阻止人民接近国外网站。选输了就下台、不合全国民意就换中央政府，没什么好挣扎的，干嘛要封网呢？路边的桃李，没说你不能摘、也没求你摘。维基百科从未阻挡贵国人编，但也不求贵国人来编。接受世界各国人士编辑与封锁某些具破坏性之漏洞都是维基全域的普遍通用原则，没必要弄什么特殊安排。如果维基基金会已表明不开放代里，那在这里说什么都没用。维基基本上未偏私任何国家，却常出现什么要维基改变形式或实质以迁就、适应中国单一国家的提议，但问题的根源是中国，不是维基。歧视中国人的正是贵国的独裁政权。中国内部的问题，该由中国内部自行解决，要维基为特定国家而改变是本末倒置。--WildCursive（留言） 2016年8月23日 (二) 15:15 (UTC)
      • (＋)支持@Wildcursive：中立中立尽量不要个人语调呢？不要攻击别人，不要攻击自己的国家。编辑维基百科的原则看过？表里不一实际上国际也没有几个国家承认所谓“中华民国”了，怎么台湾还是不敢以这名义上奥运上联合国？中国大陆离开谷歌离开维基离开推特离开facebook离开youtube，gdp也好，HDP照样！而台湾呢？你们不是要有本土意识嘛，有几个本土网能竞争竞争？还是不要小家子气啊。不就是开放代理嘛，封我就是了。是不是要等你们封锁成GFW那种类型？188.42.253.61（留言） 2016年8月24日 (三) 03:41 (UTC)


还是善意推定原则。我相信楼主是出于善意，想让来维基百科编辑的人更多，所以希望在中文维基百科可以开特例。但很可惜不能通过，原因在楼上已说过就不重复。大家也不要怪管理员们，管理员不是万能，他们只是忠实执行社群共识的维基人，此共识当然包括官方政策。--秋意假发浓(我已关闭了所有通知，所以@我看不到)（留言） 2016年8月23日 (二) 01:07 (UTC)

优先介绍改hosts，除非改hosts失败或者必须依靠绳子的话而且频密编辑的话，推荐IPE。——路过围观的Sakamotosan 2016年8月23日 (二) 10:05 (UTC)
  • 楼主走了样子[3][4]。--❦‽研究及来源 hanteng✉ 2016年8月24日 (三) 03:39 (UTC)
    • 没呢。不过好像从字体来看，我还是走吧。过两年再来看看如何。所以是Semi不是retired。Talkative Sun 2016年8月24日 (三) 05:04 (UTC)
      • 我只是关心这个议题回应是否有对你的问题进行了回答，没有希望你走或留的意思，相信你应该有所理解，不致于认为中文维基管理员或社群在这议题上有什么可以做但没有做的地方（我觉得没有了），但反过来说，你若真的有意要贡献，花一点时间读一下上述的两份文件就可以知道 （在中国）要怎么编辑维基百科比较容易，而非您开题要求的那样。--❦‽研究及来源 hanteng✉ 2016年8月24日 (三) 10:30 (UTC)

== 好的，谢谢各位！Talkative Sun 2016年8月24日 (三) 13:51 (UTC)

XsicoDNS

最新留言：在8年前发布1条留言1人参与讨论

首选115.159.157.26 备选115.159.158.38

pandaDNS的网页说11月10日的时候停止服务，不过，倒是找到了这个DNS，能正常浏览维基百科。 奇怪的是，这ip和pandaDNS一样，而且网页看上去和pandaDNS相似，我想是pandaDNS换了经营者吧(pandaDNS的跳转链接表示PandaDNS作者因为学业等不可抗拒的因素不能继续运营),看上去是pandaDNS的后代....吾...致谢列表里面也有PANDAdnsTiki pufferfish（留言） 2016年10月24日 (一) 14:35 (UTC)

编辑请求

最新留言：在7年前发布3条留言3人参与讨论

  请求已处理

XsicoDNS目前已关闭（详见其官网） --114.253.113.1（留言） 2017年9月16日 (六) 08:31 (UTC)

已经编辑该页面。--偷窥ACU的用户页/留言 2017年9月17日 (日) 07:01 (UTC)

Opera浏览器也可用于访问维基百科

最新留言：在3年前发布3条留言3人参与讨论

具体步骤请参见：[5]。如果可以的话，请将此方法写进正文中。-- Welcome to take Wuhan Metro Painjet Line! 2018年6月20日 (三) 13:57 (UTC)

请您注意：该网页内容已遭到删除。-涡轮增压 2021年1月10日 (日) 12:41 (UTC)

opera自带fq 武局南段大红枣（留言） 2021年2月7日 (日) 02:12 (UTC)

198.35.26.96疑似被封IP

最新留言：在5年前发布5条留言4人参与讨论

  请求已拒绝 CreampieGolden State Finals Champion 2018年6月23日 (六) 17:59 (UTC)

20180620起，英文版维基百科及其它的维基百科目前在中国大陆的ipv4环境下无论http还是https均无法访问（已测试北京联通/北京教育网v4路由）

疑似ip解析正常，但骨干网丢掉了前往198.35.26.96的数据包

--2001:DA8:201:2676:5D7B:617F:9F58:8449（留言） 2018年6月20日 (三) 17:38 (UTC)

似乎已经好了？ --砜中嘌呤的白磷萃取 打谱 2018年6月21日 (四) 06:47 (UTC)

存在意义？？？

最新留言：在6年前发布2条留言2人参与讨论

既然看到这个页面，就说明成功访问维基百科了，教怎么访问没有意义Skywalker is gone 2018年7月31日 (二) 14:02 (UTC)

//个人认为还是有必要的，来自一个不太会编辑主要以查证为主的用户。梯子费用比较高昂，不是所有时候都能以这种方式访问，大部分时候还是在里面的。如果能利用短暂的上网时长掌握方法，就可以授人以渔。2019年10月11日 (一) 00:16 (UTC+8)

DNS over HTTPS

最新留言：在6年前发布1条留言1人参与讨论

DNS over HTTPS 也是一种避免 DNS 污染的可行方法，能否加入该条目？--石𫁶（留言）통일렬차 달린다 2018年8月11日 (六) 05:44 (UTC)

H:VISIT

最新留言：在6年前发布12条留言11人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2018年8月16日 (四) 08:42 (UTC)。

有何存在意义？Help_talk:如何访问维基百科在此Skywalker is gone 2018年8月2日 (四) 05:40 (UTC)

解决直连或者申请在代理上豁免的需要。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月2日 (四) 12:50 (UTC)

中文维基百科疑似解封？

最新留言：在6年前发布22条留言16人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：Jimmy-bot（留言） 2018年9月11日 (二) 16:42 (UTC)。

多个地区移动网络下已经可以正常访问。--Aoke1989（留言） 2018年8月23日 (四) 01:59 (UTC)

电信和移动查114，表示你幻觉了。不过电信查114的v6地址是干净的，估计是最近开始推v6的附带产物？——路过围观的Sakamotosan | 避免做作，免敬 2018年8月23日 (四) 02:36 (UTC)
移动默认的DNS，v4污染，v6正常。如果开始下发v6地址的话，v6理论上可以用。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月23日 (四) 02:38 (UTC)
[6]，似乎部分地区的确解封了（但最近GFW似乎行事有些乖张，需要观察一段时间）--百無一用是書生 (☎) 2018年8月23日 (四) 03:14 (UTC)
感觉大部分都正常操作中，甚至见到出现v6正常地址，可能最近针对v6铺开的调整，不小心动了城墙的v4客户端配置（笑）。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月23日 (四) 08:50 (UTC)
@Aoke1989：，试一下IP登录，然后看看我的贡献显示的IP是v4还是v6。v4的话，可能是城墙客户端配置改坏了，v6的话，v6的暂时正常情况吧，以后还要看v6的城墙还能走多远。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月23日 (四) 08:50 (UTC)
看起来是因为V6地址的原因。--Aoke1989（留言） 2018年8月23日 (四) 14:38 (UTC)
现时访问有间歇性不能出现。——约克客（留言） 2018年8月24日 (五) 10:49 (UTC)
好像v4出现抢答TCPReset了。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月24日 (五) 12:19 (UTC)
@Cwek：我这边过去数个小时连hosts都“被毙了”，逼我开了一阵SS。--Liuxinyu970226（留言） 2018年8月24日 (五) 14:44 (UTC)
我这里也要开VPN了……难道墙找到新方法了？--№.N（留言） 2018年8月24日 (五) 14:59 (UTC)
应该是吧，反正目前Telegram以及QQ群里，已经有人在问这个了... --Keep Calm And Carry On, Please. 2018年8月24日 (五) 16:25 (UTC)

Hosts失效

最新留言：在2年前发布66条留言26人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：Jimmy-bot（留言） 2018年9月17日 (一) 08:42 (UTC)。

目前hosts修改所用ip似乎已经失效。请帮助确认。十分感谢。----煤桶骑士（留言） 2018年8月24日 (五) 16:19 (UTC)

山西太原的表示hosts已经挂了...--Keep Calm And Carry On, Please. 2018年8月24日 (五) 16:25 (UTC)
是这里列出的几个IP都被送进黑洞路由里了？还是SSL报头里带的明文zh.wikipedia.org被当成关键词深度包检测了？--菲菇＠维基食用菌协会 2018年8月24日 (五) 16:53 (UTC)
应该是SNI明文导致的，先访问en再访问zh使用相同IP依然可以。—思域无疆大道 事体 机器 2018年8月24日 (五) 17:02 (UTC)
看了下twitter和微博的少量反馈，似乎真的是sni rst了，据说是北京时间昨天大量部署的……--№.N（留言） 2018年8月24日 (五) 17:40 (UTC)
是的，不仅是维基百科，还有Steam社区、美国之音等一众网站也被SNI RST了，在此之前，只有Google、Facebook、Twitter等巨头网站才有这样的待遇，看来自今年8月10日TLS 1.3规范正式发布后，国家防火墙的工作人员已经开始狗急跳墙了。--Yumenghan（留言） 2018年8月24日 (五) 19:05 (UTC)
唉:-(大家快去P区安利基金会换上TLS 1.3吧。退TLS 1.2保平安。--1=0，欢迎加入WP:维基百科维护专题 2018年8月25日 (六) 01:31 (UTC)
我在twitter上所看到的其中一个关于墙大面积部署https关键字过滤的反馈就提到就算是TLS 1.3也无法绕过……传送门在这。具体我不了解，我不能保证那个反馈是否准确，望在这方面熟悉的人能够提供解释。--№.N（留言） 2018年8月25日 (六) 01:45 (UTC)
我印象中TLS 1.3的SNI不是明文的啊……--1=0，欢迎加入WP:维基百科维护专题 2018年8月25日 (六) 02:01 (UTC)
(～)补充：我去群里了解了一下，目前的SNI确实不行，需要ESNI出来了才可以。但那个现在还是草案  囧rz...--1=0，欢迎加入WP:维基百科维护专题 2018年8月25日 (六) 02:28 (UTC)
感慨，这次的封锁让我认识到什么是SNI，我才知道原来我访问什么网站墙是看得到的，他们只是看不到内容。希望“特仑苏”1.3还有ESNI能够完成吧……这次被墙抢先一步了……--№.N（留言） 2018年8月25日 (六) 07:54 (UTC)
问题是tls1.3能不能强制降级，其次是sni加密，如果能降级，还是老套路。FGT三巨头一早是主要服务入口直接黑洞，早凉透了。CDN估计难搞或者只能向CDN供应商发难。我们算照顾少了，至少还没有搞路由黑洞。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月25日 (六) 02:04 (UTC)
似乎只要用最新版本，支持TLS 1.3的浏览器就不会被降级，不支持的才会降级。我理解的是这样的。--1=0，欢迎加入WP:维基百科维护专题 2018年8月25日 (六) 02:31 (UTC)
突然脑洞，能不能找一堆肉鸡之类骚扰sniReset功能，因为这种检测是七层技术，可能需要耗费检测算力，如果找一大堆各种合规不合规的sni数据去消耗，会不会认为负载过大不划算而不使用这种策略？（笑），因为现在主要是针对UDPDNS抢答和路由黑洞这些高效策略，早期的简单TCPreset现在好像少见？——路过围观的Sakamotosan | 避免做作，免敬 2018年8月25日 (六) 03:37 (UTC)
可那旁路上的是值好多好多钱的超算啊…能处理整个国家骨干网流量的设备还是勿忧性能了吧（不过找漏洞并不是不可能，有多少人记得西厢计划来着？）。—菲菇＠维基食用菌协会 2018年8月25日 (六) 04:06 (UTC)
西厢计划的思路一直都是可以使用的，旁路以及性能问题总会有难以解决的漏洞Your State is Not Mine: A Closer Look at Evading Stateful Internet Censorship——Macronut wiki（留言） 2019年12月3日 (二) 02:22 (UTC)
  • 一个小窍门，先访问英文维基百科en.wikipedia.org，再访问中文维基百科zh.wikipedia.org就可以上了。——星耀晨曦（留言） 2018年8月25日 (六) 04:30 (UTC)
  • 部分地区可以用。-- Creampie欢迎来访 2018年8月25日 (六) 05:18 (UTC)
  • 也许该讨论下放宽申请IPBE的门槛。——笨笨de子墨(讨论) 2018年8月25日 (六) 10:11 (UTC)
  • 我找到一个关于为什么访问其他未被封锁维基百科后还能短暂访问被封语种维基百科的解释（可以的话去互联网档案馆存个档，知识问答里也有用户做出和这类似的解释）。当然，如果维基媒体基金会所有网站全被封或者对应IP被封，这个方法肯定是无效的了。--№.N（留言） 2018年8月26日 (日) 00:11 (UTC)
    • 还有就是坐等TLS1.3推广ESNI给网址加密了。--侧耳倾听 2018年8月26日 (日) 06:36 (UTC)
      • 这里我想到几个问题，一是ESNI是否有可行性（也就是能不能够实现），要是胎死腹中一辈子都得用VPN（对我来说VPN最麻烦的地方就在于时不时会掉线……），二是ESNI正式推出后，墙会怎么应对，毕竟这玩意会让Google、Twitter、Facebook等墙的重点照顾对象少去一层封锁手段，少去一层封锁手段可能会令墙推出新的封锁手段：据说墙封锁BBC刚好发生在BBC支持https之后……--№.N（留言） 2018年8月26日 (日) 07:46 (UTC)
        • ESNI能不能实现留给草案开发者去处理，不过WP的目标是构建一个知识百科全书，而不单是一个对抗审查的工具。手段只是道高一尺魔高一丈的猫捉老鼠的游戏，最后看谁斗到最后罢了。不过可以推测问题有，WP的审核级别视乎变高了，可能长期使用绕过工具的时间会变长罢了。（GTF是黑洞套餐都没说什么呢，DNS污染算是基本操作了。）——路过围观的Sakamotosan | 避免做作，免敬 2018年8月26日 (日) 08:15 (UTC)
          • 我不过是很在意不能用代理以外的手段访问维基百科罢了，我不太喜欢用代理，因为不稳定的时候经常断线，有时甚至好一段时间都连不上去……--№.N（留言） 2018年8月26日 (日) 08:25 (UTC)
            • 说的也是哦，关键的问题是维基百科在GFW里的“地位”提高了，以后墙总会换着花样搞事情，不怕贼偷就怕贼惦记。--侧耳倾听 2018年8月26日 (日) 09:15 (UTC)
              • 至少地位没Google、Facebook等那么高，如果有，估计维基百科那五个IP早就全封掉了，那样的情况下hosts同样帮不了忙。而且不要忘了这次墙的调整是令几乎所有支持https的黑名单网站都SNI RST，例如日亚、Steam社区等等等等……--№.N（留言） 2018年8月26日 (日) 09:23 (UTC)
  • 我找了一圈都没找到能够绕过SNI RST的工具，之前看过一个法国的网站（madynes.loria.fr），有个叫escape的firefox插件，但今早我试了下根本装不上……怀疑是老物了……查了下twitter关于ESNI的讨论，也有点不想指望ESNI了，ESNI据说基于DNS，现在只是草案，但假若真要这样，有一定可能改hosts会失去作用……毕竟改hosts是绝大多数中国大陆人不使用代理访问维基的（接近）唯一的方式了（其实DNSCrypt也可以，前一两周还试了下访问BBC都能用）--№.N（留言） 2018年8月27日 (一) 05:31 (UTC)
    • 我倒没问题，本身就有内网用的DNS，来源经过安全获得，所以可以不依赖Hosts。至于基于DNS，其实就是用另一条（安全）信道获得一个信任的安全令牌来处理，如果DOT或者DOHS成行的话，DNS的安全性保障了，然后TLS就可以不用完全零信任启动了。至于插件，我认为可能和FF早期可以操作底层网络连接流有关，不过现在最新的不支持旧版插件，即使是次一些版本还是因为这个插件没签名也装不了。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月29日 (三) 02:14 (UTC)
      • 嗯，现在Firefox只支持WebExtension，不支持escape插件那种用XUL做的扩展，更何况现在Firefox和Chrome都无法改SNI了，可以几乎肯定的是暂时只能乖乖用老版Firefox了。关于ESNI，如果用上DNS既令墙觉得反正SNI审查维基等网站的手段不会失效，而我们也只需要考虑如何绕过DNS这一部分，也算是OK，不过twitter上有人说ESNI捆绑DNS会令其像DNSSEC那样难以推广……---№.N（留言） 2018年8月29日 (三) 05:11 (UTC)
    • 从这份草案来看，DNS非必选机制（but other mechanisms are also possible.），只是文档定义这种机制来发布和获取公钥，然后用公钥来加密"encrypted_server_name"扩展。不过，也得网页浏览器支持其他机制输入才行，或者用特制DNS代理。Split Mode是特定服务器为特定域解密服务器名、作为转发TLS加密包的代理（似乎同SNI代理），Shared Mode是能解密名称和TLS包的服务器。要求至少TLS 1.3。Firefox在跟进。需要服务器软件及运维更新，从稳定性周期来说，还要很久。--YFdyh000（留言） 2018年8月29日 (三) 06:36 (UTC)

我做了一个实现，大家可以参考。代码在这里。原理就是每隔40秒在后台向英文维基发一个请求。这样我们的TLS会话缓存就会让我们一直可以用中文维基了。注意要在浏览器一直留一个zhwiki的标签页喔，这样才能自动发请求。实现仅供大家参考。欢迎给我的repo点星星。--1=0，欢迎加入WP:维基百科维护专题 2018年8月26日 (日) 09:28 (UTC)

给testwiki吧。这样会影响到enWP的统计数据。--Antigng（留言） 2018年8月26日 (日) 12:04 (UTC)
  • 基金会：我们又双叒叕遭到了来自中国的IP地址的DDoS攻击。(／‵Д′)／~ ╧╧
    墙：我不是，我没有，说出来你可能不太相信，是那群维基人先动手的。╮(╯_╰)╭
    --侧耳倾听 2018年8月26日 (日) 17:00 (UTC)
试过了上面提到的绕过办法，但是我这里行不通--百無一用是書生 (☎) 2018年8月27日 (一) 07:45 (UTC)
偶然是可以，不太确定原因：先en，如果先zh过肯定会不行，必须启用h2支持。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月27日 (一) 08:44 (UTC)
教育网也不能访问。--185.185.40.100（留言） 2018年8月28日 (二) 01:42 (UTC)
似乎域名前置可以对付这个问题。但首先得服务器支持，其次至少要有插件才可以（我理解没错的话）--百無一用是書生 (☎) 2018年8月28日 (二) 02:33 (UTC)
服务器目前问题不大，证书的可选域名支持很多，也不禁止不匹配，但Chrome/Firefox扩展的API改不了TLS的SNI头。我试了重定向请求再改内部'Host'请求头，能用，但地址栏地址会变成重定向后的假地址，一些脚本会因此异常（判断或存储网页域名那些），体验不好。--YFdyh000（留言） 2018年8月28日 (二) 03:13 (UTC)
域前置只能说邪门歪道，只有特定客户端才能这么干，除非打包一个专用浏览器。基金会那边会不会为此支持也有点emmm吧。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月28日 (二) 06:32 (UTC)
我想知道这个是基于什么原理（这个就是搞出escape插件的那个团队写的，没看懂所以来问）。我现在暂时用老版本的firefox加上这个escape插件，能正常访问。--№.N（留言） 2018年8月28日 (二) 12:59 (UTC)
类似域前置的方法，插件截取SNI数据后，改成其他域名发出，然后在TLS加密的host头中放上真实的域名（大概是这样？）现在不能用感觉更可能是这种方法已经不被浏览器支持--百無一用是書生 (☎) 2018年8月29日 (三) 02:14 (UTC)

还有一种“古法”：在IE6时代浏览是不发送SNI信息的，这对于维基百科来说是奏效的，因为维基百科的服务器只负责传送维基百科站点，所以证书可以在不预先知道客户端要求什么语种的情况下送出（只需*字符wildcard匹配：*.wikipedia.org就行了。)而客户端可以匹配自己的语种。所以我现在要实验一下，使用Linux开源Firefox源代码进行“SNI拔除”，专门针对维基百科。这样的话当局如果要封禁，除了禁止不发送SNI信息式访问，就只有封维基百科IP了。65.92.206.188（留言） 2018年8月28日 (二) 23:17 (UTC)

使用不支持SNI的浏览器（例如Firefox 1等）也不失为一个好办法。不过据说TLS 1.3开始要求带上SNI……这里有提到几个典型的绕过SNI封锁的几个方法……--№.N（留言） 2018年8月29日 (三) 05:11 (UTC)
“几个典型的绕过SNI封锁的几个方法”咱们这里基本都讨论到了....--百無一用是書生 (☎) 2018年8月29日 (三) 07:01 (UTC)
  囧rz...--№.N（留言） 2018年8月29日 (三) 12:43 (UTC)
看例子的话，看来审查各国都有，只是目标不同罢了，手法基本就是那几把板斧。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月29日 (三) 08:48 (UTC)
降级TLS,试了一下似乎不可行[7]？需要服务器端配合？--百無一用是書生 (☎) 2018年8月29日 (三) 09:54 (UTC)
我试了，Firefox 1基本上已经处于用不了的状态了，大部分网页都打不开，拓展也装不了，还不停弹窗警告--Space Timee（留言） 2022年4月20日 (三) 12:18 (UTC)
我是原PO主，我今早想到了一种更加巧妙的方法：不要完全拔除SNI，而是重新编程让Firefox只发送DNS域名的头两级，比如说，访问任何语种的维基百科，Firefox的SNI均只发送：wikipedia.org作为SNI host名，再比如说，访问任何谷歌博客，Firefox的SNI均只发送：blogspot.com作为SNI host名。这样做的好处是彻底失去任何墙可以用来封杀的特征（因为现在基本上所有TLS连接都带有SNI，所以不带有SNI的TLS连接反而成了一种特征，可以被墙利用进行封杀）。把＂依附的自由＂在维基百科上用到淋漓尽致，逼的墙最后不得不封杀维基百科的IP地址。66.207.125.146（留言） 2018年8月29日 (三) 12:45 (UTC)
我找到这个，看了下代码，似乎专门针对维基百科。--№.N（留言） 2018年8月29日 (三) 12:55 (UTC)
似乎还带了点附带效果。69.162.113.194这个IP应该是一个SNI Proxy吧。除了维基百科的流量，这个代理应该就直接用这个proxy了吧。我用Windows的python试了试，没成功，返回Errno 10022。我不太懂python。--1=0，欢迎加入WP:维基百科维护专题 2018年8月31日 (五) 01:37 (UTC)
我是在这找到的……说要用linux……用到windows可能要移植吧……其实linux什么效果也不能保证。说实话，要解决SNI这问题，要么DIY，做不到只能乖乖VPN……--№.N（留言） 2018年8月31日 (五) 07:57 (UTC)
因为这个是给Linux用的，Windows版在这里TCPioneer——Macronut wiki（留言） 2019年12月3日 (二) 02:21 (UTC)
有人开发了一个 nosni-proxy 应该可以绕过。另外有人提到攻击，据测试即使将sni分散在乱序的两个包中，墙依然能检测到。有兴趣的人可以考虑类似ip分片攻击的策略。2607:FCD0:100:1926:0:0:C28D:6E0D（留言） 2018年9月17日 (一) 17:23 (UTC)
墙有简陋的协议栈会拼装TCP流，IP分片是无效的TCP默认禁用IP分片，而且IP分片无法通过NAT——Macronut wiki（留言） 2019年12月3日 (二) 02:21 (UTC)
What a shame!我又不懂程序，hosts没法用了估计就只能X墙了...用英语wiki绕一遍真的不习惯  囧rz...--Huziyijs（留言） 2018年9月22日 (六) 09:59 (UTC)huziyijs

一点想法，写在讨论结束之时

上个月月底，GFW升级了审查方法，大量部署SNI RST，不过其实根据SNI提供的明文信息进行审查，早已有先例：英国有电信运营商用这招来封锁提供盗版资源的网站（上面我给的其中一个链接有说到）；韩国用这招屏蔽色情网站（我用Google搜的时候找到过有提及这点的相关讨论）；而据说土耳其也用过这招（不记得哪里看到过这说法）。所以说我们算幸运的了，至少没这么早享受到这样的待遇，至少还能在中文维基百科被封之后用hosts苟上三年（当然你也可以说墙某些方面算是落后了……），当然我们觉得至少英文维基百科还能用，不过近年来，墙正在不断地扩建，现在墙扩建的趋势不再是只针对中文网站了，据我所知似乎只要是多数中国大陆人不用翻译器就能理解至少一部分内容的境外网站都可以是他们的目标，如果确实如此，那么日文维基百科的封锁便很容易解释了，参考search.yahoo.co.jp以及search.yahoo.com现在的访问状况，我认为，英文维基百科很有可能是他们的下一个目标（顺便说下，存有不少帮助中国大陆网民绕过审查的工具的Github未来也不可能幸免于难），当然最糟糕的情况是维基媒体基金会的所有五个IP全部都会遭到封锁，加上SNI RST，可以认为未来绕过审查将变得更加困难。--№.N（留言） 2018年9月7日 (五) 06:21 (UTC)

神预言，英文wikipedia果然被封锁了。。。照这样下去。。。闭关锁国。。。大清还没亡——104.167.97.164（留言） 2019年4月25日 (四) 05:20 (UTC)

这篇wiki从头读下来，处处都是神预言--Space Timee（留言） 2022年4月20日 (三) 12:26 (UTC)

使用Chrome的插件谷歌访问助手也可以访问中文维基百科

最新留言：在5年前发布2条留言2人参与讨论

使用Chrome的插件谷歌访问助手也可以访问中文维基百科 安装地址： https://chrome.google.com/webstore/detail/%E8%B0%B7%E6%AD%8C%E8%AE%BF%E9%97%AE%E5%8A%A9%E6%89%8B/gocklaboggjfkolaknpbhddbaopcepfp?hl=zh-CN 除了要求设置为hao123为主页以外并无其他缺点，而且可以使用TamperMonkey的脚本绕开设置首页 及时雨（留言） 2018年9月22日 (六) 12:55 (UTC)94rain

备注: 除'谷歌访问助手'外,在谷歌应用商店上搜索:'谷歌访问','VPN'之类的关键词,大多能筛选出来的相应的扩展程序. (第三方代理插件有隐私风险,而且免费插件并不稳定,推荐多备用几个以便其中之一失效后,能够继续访问谷歌应用商店下载新的,可用的插件.)—以上未签名的留言由183.178.58.209（对话）于2019年12月14日 (六) 04:12 (UTC)加入。

使用Nginx本地反代无需代理服务器直连维基百科

最新留言：在4年前发布7条留言7人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2018年10月11日 (四) 08:42 (UTC)。

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：路过围观的Sakamotosan | 避免做作，免敬 2018年9月23日 (日) 11:24 (UTC)。

  • 使用OpenSSL自签证书，CN填.wikipedia.org，得到rsa.key，cert.csr，cert.crt。
  • 将rsa.key，cert.crt放入Nginx下的conf目录下，打开该目录下的nginx.conf，加入：
  • 将cert.crt导入为系统可信证书，
  • Hosts文件中的关于wikipedia的IP全改成127.0.0.1
  • 启动Niginx，即可直连。
  • 该法适用于任何被SNI阻断但IP可连接的网站。

--207.148.113.20（留言） 2018年9月23日 (日) 11:18 (UTC)

嗯......或许应该放到[[8]]？--XL-028（留言） 2018年9月24日 (一) 02:38 (UTC)

* 请注意：原讨论中生成的自签名证书会被最新版本Firefox拒绝，请参见此处的替代配置（但请删除nginx.conf的“server 198.35.26.96:443;”一行）。--GZWDer（留言） 2019年12月18日 (三) 19:00 (UTC)

请这位电脑小白不要瞎指捣，众所周知：Firefox自带证书库，不调用系统证书！Firefox用户可以在 选项-高级→证书→查看证书→证书机构→导入 导入自己的自签证书。--185.186.245.44（留言） 2020年1月23日 (四) 01:51 (UTC)

DNS的疑问

最新留言：在2年前发布3条留言3人参与讨论

看到文中写到中科大和清华大学的DNS可以访问被封锁的网站，那么他们的校内网是一种无视墙的存在吗？——104.224.133.18（留言） 2018年12月3日 (一) 12:48 (UTC)

他们校园网的DNS服务器做了防污染相关的处理罢了--Space Timee（留言） 2022年4月20日 (三) 12:45 (UTC)

此方法现在已经失效了，那两个估计是漏网之鱼.或者学校当时有特殊用途——Raindrops2005（留言）2019年4月27日 (六) 11:23 (UTC)

可以在匿名ip的讨论页上举报该ip疑似公用代理服务器吗？

最新留言：在6年前发布1条留言1人参与讨论

如题，详见User_talk:103.114.161.158，其中本人提供了确凿的证据（提供该公共代理服务器的来源页面（有详细的ip等信息）），不知道这样是否可行？（主要还是为了防止被他人滥用此ip来进行破坏和编辑战） 咸鱼老李（留言） 2018年12月9日 (日) 11:15 (UTC)

为什么Help:如何访问维基百科和m:Help:如何访问维基媒体旗下项目里提供的网址有问题

最新留言：在6年前发布15条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2018年12月15日 (六) 08:14 (UTC)。

为什么text-lb.(资料中心名).wikimedia.org和upload-lb.(资料中心名).wikimedia.org会凭证会解析错误？-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 00:00 (UTC)

“會憑證會解析錯誤”，每一个字都懂，但是整句话就看不懂了。大陆测试过，4和6的地址都能解析出。“(资料中心名)”指上面五个数据中心的标示名。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 05:26 (UTC)
@Cwek：随手乱打的，其实是为什么无法辨识凭证？-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 06:07 (UTC)
TLS证书吗？没发现问题。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 06:11 (UTC)
ex:https://text-lb.ulsfo.wikimedia.org/会返回

User:Cwek-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 09:07 (UTC)

正常啊，因为这些证书的CN和扩展域名都没有包括wikimedia.org的多级子域名。可以理解为a.com配了b.com的证书，只不过b.com的a记录指向a.com的地址。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 09:22 (UTC)
User:Cwek那要去哪里根基金会反映？顺带一提，可不可以使用{{ping}}回复一下？-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 10:45 (UTC)
嗯，说得难听的，我感觉你是技术不太全懂但又瞎操心。没必要，这是设计需要，这些IP配置的域名相当于一种方便自动管理的管理用域名，也就是说，证书的域名配置是无问题的，而这些IP的域名是方便基金会管理这些这些IP而设置，证书上不配置这些域名并无必要。例如国际大型ISP的路由设备的IP地址也配置了域名，但是实际路由并不需要这些域名，更多是企业内部方便管理的作用（例如结合域名识别IP设备的部署位置、管理控制等）。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 12:32 (UTC)
User:Cwek因为现在是Google Chrome挡掉不给过，Internet Explorer也不给过，什么都不给过-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 13:01 (UTC)
没发现证书有问题，说一下你在研究什么技术？我是直接用代理附带的端口转发能力，直接通过加密代理出去，然后转发到基金会的地址上。证书一切正常，除了需要用内网DNS修正域名到内网的端口转发地址上。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 13:16 (UTC)
代理或许没这个问题，但台湾又没有GFW当然是直连的User:Cwek-- Sunny00217 --维基餐厅开幕了，欢迎参观。 2018年12月2日 (日) 13:29 (UTC)
如果在台湾的话，折腾这个域名没用的。这个域名主要是给基金会用来管理设备用的，或者给我们大陆找IP的小作弊方法。直接访问这个域名是没用的。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 13:58 (UTC)
那么就应该说明那个域名是给谁用的啊。看正文看不出来跟大陆有关:)我知道这里有尽量委婉的需求，不过也应该保证尽量让人看懂吧。 --122.211.109.58（留言） 2018年12月5日 (三) 02:54 (UTC)
我觉得这种技术性数据，基金会不会主动告诉你是什么，或者怎么用。（我也怀疑最初是有人检查这些IP与域名信息时偶然发现关联？）就像那些国际大型ISP那样，也不会公开解释路由器设置的域名有什么用。（更何况中国电信大部分路由设备或者终端IP连这个域名都不设的）——路过围观的Sakamotosan | 避免做作，免敬 2018年12月5日 (三) 06:02 (UTC)

昨天2620:0:861:ed1a::1和2620:0:863:ed1a::1都被屏蔽了

最新留言：在2年前发布5条留言3人参与讨论

昨天（2019年1月18日下午）2620:0:861:ed1a::1和2620:0:863:ed1a::1都被屏蔽了，2620:0:862:ed1a::1和2001:df2:e500:ed1a::1还可用。2001:4860:4860::8888也被屏蔽了。其他人可以用以上IP直连吗？--Midleading（留言） 2019年1月19日 (六) 01:44 (UTC)

刚刚2620:0:862:ed1a::1也屏蔽了。--Midleading（留言） 2019年1月19日 (六) 10:46 (UTC)
晚上，2001:df2:e500:ed1a::1被屏蔽了，这样维基百科将无法通过IPv6访问。--Midleading（留言） 2019年1月19日 (六) 14:16 (UTC)
初步测试了，除了新加坡外，其他只要是接入教育网的都不行。暂时发现联通都能ping通。可用性不明。——路过围观的Sakamotosan | 避免做作，免敬 2019年1月24日 (四) 02:53 (UTC)
刚刚测试，目前电信对以上ip均可ping通--Space Timee（留言） 2022年4月20日 (三) 13:02 (UTC)

能不能在IIS上搭建反向代理

最新留言：在5年前发布1条留言1人参与讨论

如题，手头上没有Nginx，也懒得装（懒癌晚期）……忒有钱（留言） 2019年2月11日 (一) 14:08 (UTC)

GFW在测试新功能？？？

最新留言：在5年前发布17条留言9人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2019年4月14日 (日) 16:14 (UTC)。

我平时通过修改Hosts上中文维基百科，然而这次按照先上英文维基再上中文维基的顺序访问中文维基百科的时候，中文维基百科却打不开了，Firefox显示“连接被重置”或者“连接超时”，同时连带所有维基媒体的项目都上不去了，错误提示和访问中文维基时一样。以上情况并非每次都发生，而是有一定概率的，各位遇到这类情况了吗？难道是GFW在测试新功能？--侧耳倾听 2019年3月23日 (六) 15:44 (UTC)

英文维基百科疑似被DNS污染

最新留言：在5年前发布21条留言9人参与讨论

今天（2019年4月23日）访问英文维基百科显示超时，DNS解析显示地址被解析至Facebook等网站。本人在广州教育网内，但是通过ping检测工具发现是全国性问题。目前未见SNI检测。不知是暂时故障还是被安排上了 120.236.174.159（留言） 2019年4月23日 (二) 02:42 (UTC)

大概率是安排上了（近些年来几乎没听说过有哪个网站封了一段时间又解封的），而且不止英文维基百科，试了ping下韩文维基百科也是如此。--№.N（留言） 2019年4月23日 (二) 02:53 (UTC)
真可惜，英文也GG了——Thyj (通知我) 2019年4月23日 (二) 06:57 (UTC)
这个改动之后目前暂时正常了，不过不排除近期访问情况有再次发生变化的可能。--№.N（留言） 2019年4月24日 (三) 02:46 (UTC)
更新：目前墙已经针对这个改动做出及时调整，全部语种维基百科再次无法访问。--№.N（留言） 2019年4月24日 (三) 03:33 (UTC)
好像现在不止DNS了，连SNI RST也用上去了。--№.N（留言） 2019年4月24日 (三) 13:51 (UTC)
确实，用Google Chrome连接时显示是RESET型的报错，看来确实是安排上了。--User:Yatogamihoza（留言） 2019年4月24日 (三) 14:07 (UTC)
似乎从Commons绕过去还行，当然迟早还是得用上本地反代，甚至VPN --120.236.174.170（留言） 2019年4月24日 (三) 15:59 (UTC)
好像确实可以，这跟当年的游击战没啥区别了（无奈）--User:Yatogamihoza（留言） 2019年4月25日 (四) 14:23 (UTC)

如果还是上不了，以后貌似只能看垃圾百度百科了——Thyj (通知我) 2019年4月25日 (四) 03:22 (UTC)

自从知道了维基，再也没去过垃圾百度百科一次，真实粪堆。--User:Yatogamihoza（留言） 2019年4月25日 (四) 14:25 (UTC)
赞同楼上观点，百度现在变成百毒了--User:Raindrops2005（留言） 2019年4月27日（六）11:13 (UTC)
我就想知道现在修改HOST还能上吗，现在用的代理很慢——2A00:E60:7000:100:6:0:0:1（留言） 2019年5月2日 (四) 10:08 (UTC)
从其他维基媒体上跳转吧，跟以前从其他语言维基百科跳转一个道理。--User:Yatogamihoza（留言） 2019年5月7日 (四) 03:39 (UTC)

现在连共享资源、数据库也上不了了  囧rz……——Thyj (通知我) 2019年5月9日 (四) 04:46 (UTC)

现在应该是只是DNS污染，未来不久应该会上SNI RST或者直接IP封锁。如果是后者，那么大陆维基人全体VPN的时代即将到来。--№.N（留言） 2019年5月9日 (四) 04:53 (UTC)
看起来是 CNAME 到 www.wikipedia.org 导致的污染扩大。使用国外 DNS 服务器这些域名可以获得正确的结果。 lilydjwg 交流 2019年5月9日 (四) 05:13 (UTC)
和phab:T208263这个修改有关，某位程序认为应该将所有域名CNAME到一个特定域名，来优化各域名的缓存时间。起初在wikipedia.org根域做测试，结果先是DNS直接污染，跟着是整个根域被SNI RST了，由于无法判断是不是和这个CNAME修改有关，推测只是偶然相关。现在他测试全部CNAME到www.wikipedia.org，而www.wikipedia.org是被污染的，现在我怕CNAME传染的理论是正确的，所以有必要的请多多去反对，这种优化太吃力不讨好了。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月9日 (四) 06:51 (UTC)
@Cwek：我觉得优化还是有必要的，所以我想可以让他CNAME到没有DNS污染的域名（比如说www.wikimedia.org）。-- FL.YL.BANxS（留言） 2019年5月9日 (四) 11:32 (UTC)
姑且我认为有些可以的冒险，可以测试下CNAME会不会导致污染扩散（正如我所说，是几乎全部对外域名），但一旦证实的话，以为如User:Liu116所说的。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月9日 (四) 12:03 (UTC)
最初是CNAME到wikipedia.org，然后*.wikipedia.org被封锁。因此我认为如果封锁会随CNAME扩散，这样做的话封锁应该会扩散到*.www.wikimedia.org而不是所有项目。-- FL.YL.BANxS（留言） 2019年5月9日 (四) 12:30 (UTC)
其实我想说的是，与其让未被封锁的域名CNAME到被封锁的域名，不如让未被封锁的域名CNAME到未被封锁的域名。-- FL.YL.BANxS（留言） 2019年5月9日 (四) 12:43 (UTC)

提议删去Help:如何访问维基百科中的无效方法

最新留言：在5年前发布28条留言8人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2019年5月14日 (二) 16:15 (UTC)。

去年8月末中国大陆部署了SNI RST，自那时起就无法单纯透过修改 hosts 访问维基百科。现在Help:如何访问维基百科页面趋于臃肿。

针对该帮助页，在2.1节下添加绕过SNI RST的方法，删去2.2节以及所有失效的镜像网站（Help:如何访问维基百科#镜像网站，引用自WP:维基百科拷贝网站）。--YouTable 2019年5月1日 (三) 09:00 (UTC)

我觉得删掉没问题，现在的确实太复杂，一下子搞不明白哪个可以用。H:HOSTS 这个快捷方式可以考虑取消章节重定向，就到这个页面本身。 --砜中嘌呤的白磷萃取 打谱 2019年5月1日 (三) 07:28 (UTC)

其实修正域名解析那一节已经有绕过SNI RST的方法了。DNS那一节还有IPv6 DNS和中科大DNS（目前可用，虽然划掉了）可用。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 09:15 (UTC)

(：)回应：那就把 hosts 整节删了（或是移到下面），把下面的本地反代移上来。不然过于混乱，无法让读者直观地知道到底哪些能用哪些不能用。--YouTable 2019年5月1日 (三) 09:38 (UTC)
Hosts比其他方法更加稳定，因为DNS和DoT/DoH的服务器容易被封，所以不能删，而且最稳定的方法应该放到前面。 -- FL.YL.BANxS（留言） 2019年5月1日 (三) 09:51 (UTC)
但现在直接改hosts在中国大陆不可用。--YouTable 2019年5月1日 (三) 09:54 (UTC)
怎么不可用？Hosts、DNS、DoT/DoH的作用都是一致的，都用于得到不受污染的DNS结果。然后绕过SNI RST。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 09:59 (UTC)
也就是说，改hosts还是用DNS或DoT/DoH的效果是一样的。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 10:08 (UTC)
直接改hosts确实不可用，但是修正域名解析这个章节所提供的方法都不能直接使用，都需要绕过SNI RST。但是Hosts不需要经过服务器，所以相对于其他方法来说Hosts更稳定。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 13:32 (UTC)
应该直观地提供有效的方法。应该把下文的本地反代移上来，其余的需要另外采取措施绕过SNI RST的放下面去。这个帮助页的目的就是为了解决如何访问维基百科，所以理应把有效的方法放在显要位置。--YouTable 2019年5月1日 (三) 20:35 (UTC)
本地反代可以移上来。同时可以把DoT/DoH移到DNS前面。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 01:19 (UTC)
其实修正域名解析+这种脚本就比较方便了。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 01:48 (UTC)
虽然这种方法不如本地反代可靠，但是无法搭建本地反代的设备（如未root或越狱的移动设备）可以用。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 02:13 (UTC)
其实本地反代有安全性问题，因为nginx连接上游服务器时不验证证书（因为不发送SNI而且证书不能包含IP地址，所以即使没受到攻击证书也会无效，所以只能不验证）。而修正域名解析+绕过SNI RST是直接与服务器建立连接而且带上SNI，从而可以验证服务器证书是否有效。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 06:43 (UTC)
说错了，是先访问没被SNI RST的域名得到证书缓存，然后用证书缓存建立连接。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 04:01 (UTC)
举个例子：
  • 不安全连接（类似于nginx本地反代的访问方法）：curl https://198.35.26.96 -H 'Host: zh.wikipedia.org' -v -k，直接用IP地址发起连接；忽略证书错误。
  • 安全连接：curl https://mediawiki.org -H 'Host: zh.wikipedia.org' -v，用没被SNI RST的域名发起连接；简单的域前置方法，普通的浏览器做不到。 -- FL.YL.BANxS（留言） 2019年5月2日 (四) 06:43 (UTC)
纠正一下，本地反代并非只有nginx那个方法，如使用Accesser，默认情况下就会校验证书，以保证安全。-- 几何原本 2019年5月2日 (四) 06:35 (UTC)
那这样就没关系了。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 06:43 (UTC)
(＆)建议将长期无效的镜像站存档。--及时雨 留言 2019年5月1日 (三) 13:07 (UTC)
可以，既然无效了留着也没什么用。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 13:32 (UTC)
无效应该分为被封锁的网站和完全关闭的，仅仅被封锁的网站留在Wikipedia:维基百科拷贝网站（不嵌入Help:如何访问维基百科），完全关闭的网站应该删除。—以上未签名的留言由2001:da8:201:3512:bce6:d095:55f1:36de（对话｜贡献）于2019年5月1日 (五) 15:31 (UTC)加入。
存档还不如删去，编辑历史可见。--YouTable 2019年5月3日 (五) 02:36 (UTC)

FL.YL.BANxS已经把本地反代一节移上来了。目前无效镜像的去留还需要讨论。现计划删去所有已经失效的镜像网站。有其他意见者请提出，也请较早前发表过意见的User:FL.YL.BANxS、User:WhitePhosphorus发表意见，谢谢。--YouTable 2019年5月3日 (五) 03:52 (UTC)

我认为可以先把所有的红标网站加上<noinclude>，然后再把真正关闭的网站删除。-- FL.YL.BANxS（留言） 2019年5月3日 (五) 11:05 (UTC)
@FL.YL.BANxS：如何查证？--YouTable 2019年5月4日 (六) 02:23 (UTC)
对域名进行DNS查询，然后把NXDOMAIN（域名无解析记录）的删除。剩下的用代理访问，然后把打不开或停止服务的网站删除。-- FL.YL.BANxS（留言） 2019年5月4日 (六) 03:25 (UTC)
现在Help:如何访问维基百科#镜像网站已经没有红色了（被<noinclude>、</noinclude>了）-- Sunny00217 - 2019年5月4日 (六) 13:42 (UTC)

修改火狐浏览器关于SNI的部分

最新留言：在5年前发布20条留言8人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2019年5月31日 (五) 16:14 (UTC)。

以下是火狐浏览器源代码中关于SNI的ClientHello语句生成函数，是一个关键性函数，通过浏览器发送的任何SNI请求都必须经过此函数生成ClientHello。这个函数来自于火狐浏览器源代码文件系统下的security/nss/lib/ssl/sslext3.c文件： 

/* Format an SNI extension, using the name from the socket's URL,
 * unless that name is a dotted decimal string.
 * Used by client and server.
 */
PRInt32
ssl3_SendServerNameXtn(sslSocket * ss, PRBool append,
                       PRUint32 maxBytes)
{
    SECStatus rv;
    if (!ss)
        return 0;
    if (!ss->sec.isServer) {
        PRUint32 len;
        PRNetAddr netAddr;

        /* must have a hostname */
        if (!ss->url || !ss->url[0])
            return 0;
        /* must not be an IPv4 or IPv6 address */
        if (PR_SUCCESS == PR_StringToNetAddr(ss->url, &netAddr)) {
            /* is an IP address (v4 or v6) */
            return 0;
        }
        len  = PORT_Strlen(ss->url);
        if (append && maxBytes >= len + 9) {
            /* extension_type */
            rv = ssl3_AppendHandshakeNumber(ss, ssl_server_name_xtn, 2);
            if (rv != SECSuccess) return -1;
            /* length of extension_data */
            rv = ssl3_AppendHandshakeNumber(ss, len + 5, 2);
            if (rv != SECSuccess) return -1;
            /* length of server_name_list */
            rv = ssl3_AppendHandshakeNumber(ss, len + 3, 2);
            if (rv != SECSuccess) return -1;
            /* Name Type (sni_host_name) */
            rv = ssl3_AppendHandshake(ss,       "\0",    1);
            if (rv != SECSuccess) return -1;
            /* HostName (length and value) */
            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)ss->url, len, 2);
            if (rv != SECSuccess) return -1;
            if (!ss->sec.isServer) {
                TLSExtensionData *xtnData = &ss->xtnData;
                xtnData->advertised[xtnData->numAdvertised++] =
                    ssl_server_name_xtn;
            }
        }
        return len + 9;
    }
    /* Server side */
    if (append && maxBytes >= 4) {
        rv = ssl3_AppendHandshakeNumber(ss, ssl_server_name_xtn, 2);
        if (rv != SECSuccess)  return -1;
        /* length of extension_data */
        rv = ssl3_AppendHandshakeNumber(ss, 0, 2);
        if (rv != SECSuccess) return -1;
    }
    return 4;
}

其中关键性的代码为如下两行： 

        len  = PORT_Strlen(ss->url);

以及： 

            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)ss->url, len, 2);

其中ss->url是目标网站域名，也就是SNI的域名（也就是唯一可以被墙看见的那个域名）。为只读变量，不能修改（而且也不应该被修改，因为后续收到安全证书以后必须要能对上安全证书里的域名列表里的某一个域名，而且再后续进行HTTPS GET操作时就必须要有正确的域名才能取得正确的网页和内容）。

但是（我要说但是了！）我们可以把在以上两行里的ss->url完全替换成【另外】的一个string literal（也就是所谓的“hard-coding SNI”）。比如以下两种修改： 

        len  = PORT_Strlen("wikimedia.org\0");
…
            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)"wikimedia.org\0", len, 2);

        len  = PORT_Strlen("\0");
…
            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)"\0", len, 2);

都能通过编译器编译，生成火狐浏览器的目标文件（object files）以及可执行二进制文件（binary executable）。我对以上两种情况分别进行了实验，有以下发现：

  • 如果hard-code空字符串\0，那么所有HTTPS连接一律报错，没有例外，也就是说如此编译出来的浏览器是完全废掉了。（这种情况对应于“SNI拔除”，也就是试图把现代火狐浏览器恢复到火狐浏览器1.0时代不发送SNI信息，现在看来这种方法完全行不通了）
  • 如果hard-code维基媒体总站域名，那么在我测试的网站中，除了Cloudflare网站不能正常工作，其它网站都能正常工作。特别有趣的是对谷歌发送维基媒体总站域名SNI也能得到正确的谷歌证书，成功打开google.com，而浏览器不会报错。（这种情况对应于域名前置，当然都是维基媒体的域名，所以应该也无所谓，不存在欺骗性质，和被亚马逊和谷歌禁止的那种域名前置行为有本质上的区别）

甚至可以做出如下修改： 

char url[500];
scanf("%s", url);
…
        len  = PORT_Strlen(url);
…
            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)url, len, 2);

当然，以上修改后的火狐浏览器需要从xterm终端里启动，否则没法输入字符串。我个人从未做出或者测试过以上修改。但是我相信以上的修改是最最灵活的，因为允许用户在运行火狐浏览器的时候自行键入想要送出的明文SNI域名。

很可惜，我身在墙外，所以完全不知道这些修改能不能规避墙的SNI重置封锁。但是如果墙内朋友证实这些修改是可行的话，那么这将是非常powerful的修改。这些修改将允许墙内网友浏览维基百科直到墙SNI封杀【最后一个】维基媒体域名（现在除了维基百科和维基新闻以外基本上所有其它维基媒体域名都未被墙封杀）。而且墙内网友可以直接打开维基百科，而不需要先打开比如维基文库，然后利用HTTPS信道余热来打开维基百科。

不爱思考得猪（留言） 2019年5月17日 (五) 20:44 (UTC)

会编译，看得懂代码的人为什么需要这个...--Fantasticfears（留言） 2019年5月17日 (五) 21:34 (UTC)
其实说实话这是一个比较针对维基媒体的特定修改，而且可能也用不了多久了。墙不知道为什么没有对维基媒体进行全面封杀，而是只封杀了维基新闻和维基百科两类域名。以上的修改就是利用剩下的、未被封杀的维基媒体域名进行一种类似域名前置的操作，使得墙内用户在不翻墙的情况下依旧可以使用维基百科。但是说实话我个人是不太看好这个hack的，因为我认为墙应该即将封杀所有维基媒体域名了，甚至可能会对维基媒体的服务器群进行彻底IP封杀。不爱思考得猪（留言） 2019年5月17日 (五) 23:20 (UTC)
其实就是，一种是SNI拔除，一种是类似域前置的方法。曾经有讨论过，不过需要定制化的客户端，只能适合硬核玩法。至于域前置的做法，好像有几家CDN不再支持了，为了防止Telegram等利用。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月18日 (六) 00:52 (UTC)

Success!!! This is 不爱思考得猪. I have tunneled back inside the Great Firewall of China using PureVPN's Shanghai server. I have tested and verified that the above changes I have made to Firefox's source code really worked (together with relevant changes to /etc/hosts). Right now I am accessing zh.wikipedia.org with SNI wikimedia.org. I do apologize for posting this exciting update in English as my Firefox testing environment is Ubuntu Linux, so I cannot input Chinese. Look at my signature and you can see that the IP address is located in Shanghai. I am so happy right now! 101.226.196.139（留言） 2019年5月19日 (日) 19:58 (UTC)

成功啦！成功啦！昨天我订购了PureVPN服务，PureVPN有服务器在上海，连上去了以后果然就是墙内的环境。我修改的火狐浏览器是在Ubuntu上运行的，所以刚才成功了以后留言记录证明连接成功只能打洋文了。要注意的是我对于火狐浏览器的修改必须要搭配/etc/hosts修改才行。在修改了/etc/hosts以后，运行Ubuntu内置火狐浏览器，就会收到“SNI Reset”错误信息。而运行我修改的火狐浏览器，则可以在未打开wikimedia.org的情况下直接打开zh.wikipedia.org，而且速度良好。今天我真是太高兴啦！这个修改应该可以一直使用到墙封杀维基媒体旗下的最后一个域名。不爱思考得猪（留言） 2019年5月19日 (日) 20:27 (UTC)

你很厉害嘛。但你如果不编译出来的话，我们这些小白可是用不了呢。不过Firefox升级后就又不能用了吧。虽然我有其他方法啦。--1=0，欢迎加入WP:维基百科维护专题 2019年5月19日 (日) 23:19 (UTC)
多谢Misel兄夸奖！我下来琢磨琢磨如何编译出视窗平台上的火狐目标文件、库文件、可执行文件。不爱思考得猪（留言） 2019年5月20日 (一) 13:37 (UTC)
其实说实话我到现在也没有在视窗平台上开发过任何正经程序。习惯了在Linux上码农，Linux的确比视窗对码农更加友好。不爱思考得猪（留言） 2019年5月20日 (一) 14:51 (UTC)
我修改的火狐浏览器和Firefox主线升级没有任何关系。主线Firefox升级了以后，我修改的火狐浏览器还是能够正常工作的，只不过就是版本老一些而已。不爱思考得猪（留言） 2019年5月20日 (一) 14:53 (UTC)
或者将这个做成一个可以外部配置读取的配置文件，判断域名是否需要SNI修正，不需要的话就照常，需要的话就修正。不过还是那句，硬核玩法。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月20日 (一) 01:20 (UTC)
多谢cwek兄的建议，我试着创造一个外部配置读取的配置文件。同时我再实验几种其它的灵活改变SNI方法看看效果如何。不爱思考得猪（留言） 2019年5月20日 (一) 13:37 (UTC)

各位，我已经上了Mozilla-Dev瞄了几眼，在视窗上编译火狐浏览器需要40个G的空间。我现在使用的视窗笔记本电脑💻没有这么多空间（因为是固态硬盘SSD），所以明天我先要去Best Buy买一台新的笔记本电脑💻，以传统旋转磁硬盘（HDD）为主（这样空间足够大），然后再开始安装Visual Studio等视窗编译环境，然后开始修改视窗版火狐浏览器源代码，然后开始编译视窗版火狐浏览器。整个过程最长可能要花上几个礼拜的时间。所以这段讨论基本上可以存档到“如何访问维基百科”里面了，等我以后有更新了再开一个新话题告知修改版视窗火狐浏览器的下载地址。不爱思考得猪（留言） 2019年5月20日 (一) 17:23 (UTC)

如何确保分发的二进制文件中仅有相关部分被改变？-Mys_721tx（留言） 2019年5月20日 (一) 21:21 (UTC)
哈哈，这位兄台问的问题很好，以下是我的一些想法：
  • 我以人格担保，我修改的火狐浏览器里绝对不夹杂私货！（当然这是最最薄弱的一种说辞）
  • 你可以把我分享的文件与官方发行版火狐浏览器文件做一个二进制diff，你会观察到唯一的不同就是libssl3.so（视窗上应该是libssl3.dll），而且你把不同的那些字节调出来进行反汇编（disassembly）以后会发现反汇编出来的那些指令正是我所添加的C语句的x64汇编语言版本。（当然这么做对于很多人来说是非常有难度的）
  • 最好的方法当然是你自己去下载火狐官方源代码，自己去到ssl3ext.c里做出修改，然后自己为自己编译一个火狐浏览器。这也就是为什么我这么详细的把要具体修改的东西在本客栈里贴出。我的初衷是让所有人自行去修改源代码然后编译，因为我真的不觉得这么做有任何难度（特别是当我已经为你们摸清楚了源代码里究竟是哪个函数在控制着SNI）。
  • 还有就是把这个功能要求Mozilla添加到Nightly里面去。（我不认识Mozilla的人，而且这种修改基本上不可能被Mozilla接受。）
如果其它维基人还能想出什么好的保证机制请自由的往以上列表里添加。不爱思考得猪（留言） 2019年5月21日 (二) 01:40 (UTC)


这其实等价于挂个HAProxy反向代理，然后中间人篡改下SNI……写几行配置就成，还不用重新编译。--菲菇＠维基食用菌协会 2019年5月20日 (一) 23:41 (UTC)

哇！😍😍😍😍😍😍😍😍😍😍😍😍真的吗？！那么还烦请菲菇兄能在本楼贴出使用反向代理篡改SNI的详细具体操作教程，以及兄所说的那几行配置。就像我在本楼里具体精确的指出需要修改火狐浏览器源代码的哪一个文件里的哪一个函数里的哪几行代码，以及怎么修改那几行代码。谢谢！不爱思考得猪（留言） 2019年5月21日 (二) 01:46 (UTC)
奇技淫巧，不如肉翻。--菲菇＠维基食用菌协会 2019年5月21日 (二) 05:54 (UTC)
菲菇兄这话说的在理儿！不爱思考得猪（留言） 2019年5月21日 (二) 13:09 (UTC)

半突发新闻

最新留言：在5年前发布16条留言6人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：Jimmy-bot（留言） 2019年12月19日 (四) 08:14 (UTC)。

text-lb的旧金山节点地址疑似上名单了，大致时间为12月1日（见Help:如何访问维基百科历史）。请自行按需技术调整。  囧rz...——路过围观的Sakamotosan | 避免做作，免敬 2019年12月1日 (日) 12:14 (UTC)

维基媒体域名被DNS污染了吧，如mediawiki.org、wikidata.org--Zyksnowy（留言） 2019年12月1日 (日) 19:12 (UTC)
没有发现污染，只是大部分站点使用了统一缓存CNAME地址，而那个地址对于中国大陆访问最近的是旧金山缓存点。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月2日 (一) 00:43 (UTC)
另外补充，现在海缆中断频发，电信已确定去wmf的路由（也就是zayo的线路）全部绕欧洲。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月2日 (一) 01:02 (UTC)
墙IP只是时间问题，近些年来墙多次干扰维基媒体基金会项目的访问，相信不久的将来维基百科的封锁级别会向Google看齐。--求🔨得🔨 2019年12月2日 (一) 01:16 (UTC)
近期墙动作也是不少，以前用来存档的archive.is只是DNS污染，周末的时候发现也上了SNI了。--求🔨得🔨 2019年12月2日 (一) 01:20 (UTC)
其实SNI和以前的明文HTTP没太大差别。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月2日 (一) 02:13 (UTC)
另外，还是那句：莫猜朕意，猜不透的。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月2日 (一) 02:13 (UTC)
趁IP还存活，推荐大家个工具TCPioneer，和INTANG工作原理相似通过修改发出的TCP包来避免SNI检测，所以没有MITM没有代理，可以访问包括Google在内所有被SNIRST的网站。——Macronut wiki（留言） 2019年12月3日 (二) 01:41 (UTC)
记得Google是直接封IP的。--求🔨得🔨 2019年12月5日 (四) 01:32 (UTC)
自从ip被封后我就把ip的最后一个字节左右移几位来ping，想看一下有没有邻近服务器，结果还真有，比如说198.35.26.96的最后一个字节是96，+1就是97：curl https://www.mediawiki.org/ --connect-to ::198.35.26.97: -v4。以此类推，在大部分IPv4的text-lb可用（eqiad不行，IPv6未测试）。看起来应该是基金会的服务器吧，毕竟TLS证书都是有效的。-- FL.YL.BANxS（留言） 2019年12月6日 (五) 04:08 (UTC)
看了下反向DNS，是test-lb.ulsfo.wikimedia.org，看起来是测试服务器？-- FL.YL.BANxS（留言） 2019年12月6日 (五) 04:27 (UTC)
我3日就测出来了。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月6日 (五) 06:35 (UTC)
欧洲节点也有类似的test入口。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月9日 (一) 01:54 (UTC)
更准确来说，是每个节点都有一个这样的入口。——路过围观的Sakamotosan | 避免做作，免敬 2019年12月9日 (一) 03:02 (UTC)

维基百科全站已经解封？！

最新留言：在4年前发布3条留言3人参与讨论

中国移动ip实测，不论英文版中文版法语版粤语版，不论网页移动，甚至是某些敏感词条，皆能够正常打开。 由于疫情关系忘记封锁了？！可是，例如维基新闻能打开，维基学院，维基文库，维基教科书等等又不行.. ps..我这是ipv4测试. 使用明文版链接会自动跳转到https正常访问.—以上未签名的留言由113.20.22.116（对话）于2020年4月2日 (四) 10:55 (UTC)加入。

坐标广东也是中国移动ipv4实测百科，新闻已经全站解封，其他的未测试—以上未签名的留言由23.130.224.40（对话）于2020年4月17日 (五) 09:09 (UTC)加入。

5月中又封了。--一片🍁枫叶DC18#3000编辑，冲啊！#热烈庆祝珠机城际通车！ 2020年8月20日 (四) 12:42 (UTC)

请问维基百科是何时被封IP的？

最新留言：在4年前发布11条留言5人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助/存档/2020年3月。

印象当中好像很长一段时间是DNS污染，后来升级成了SNI封杀。近期查询“如何访问维基百科”页面，赫然发现所有项目都打叉了。推断维基百科乃至整个维基媒体的服务器都被封杀IP了。所以想来询问一下究竟是什么时候的事情？

另外维基百科有没有意向使用Cloudflare的CDN网络进行托管？

172.97.161.17（留言） 2020年3月13日 (五) 23:14 (UTC)

对技术小白而言，你们自然有方法去粗暴解决这些问题，细节了解也没有啥意义。对于非技术小白的话，关注Help_talk:如何访问维基百科能了解一些最新情况，而且我们也很及时地Help:如何访问维基百科的信息，对吧。（微笑）——路过围观的Sakamotosan | 避免做作，免敬 2020年3月14日 (六) 02:56 (UTC)
CDN好像有人讨论过，好像是涉及隐私问题。其实现在多个缓存点就是相当于CDN机制。只是不在国内建立接入点，没特别配置的线路一样烂，就算你挂Cloudflare也一样。Cloudflare在中国和百度合作有接入点，不过同样需要行政审核申请。如果不用中国接入点，移动最近可以去香港的接入点，但电信的只能去美国旧金山，至于去美国的普通线路……嗯，你懂的。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月14日 (六) 02:56 (UTC)
CDN也可以搞keyless嘛。@Cwek：试试trace基金会几个DC的IP，它们都走了CF的路由。--Techyan（留言） 2020年3月14日 (六) 18:39 (UTC)
吹牛打定好定稿先好不，或者看下wikitech:Network design再说好不？最多就买了专线来连接DC，但是有走cf的路由的有点浑水摸鱼或者纯粹瞎猜吧。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月15日 (日) 01:51 (UTC)
俺选择tracert了下，部分节点真的走CloudFlare，也就是下面的两跳108.162.214.152。俺记得Twitter上有人号称把基金会DC打趴下过，俺估计是用来防止有人DDoS的。俺把tracert的最终几跳结果放在这里，供各位参考。--痛心疾首（留言） 2020年3月16日 (一) 11:20 (UTC)
……
  8     *      163 ms     *     202.97.90.118
  9   154 ms   139 ms   139 ms  218.30.54.214
 10   164 ms   164 ms   164 ms  108.162.214.152
 11     *      162 ms     *     108.162.214.152
 12     *        *        *     请求超时。
 13   291 ms     *      261 ms  text-lb.eqsin.wikimedia.org [103.102.166.224]
有点意思，可能新加坡DC有接入cf而且也买了cf的承载？对于移动来说会开心，因为移动的出口在香港并有接入到香港交换中心，cf在香港交换中心也有接入，非常顺路。对于电信来说，没啥差别，美国本部还是走欧洲zayo，而去新加坡就是环太平洋游。  囧rz...可能需要问基金会确定？——路过围观的Sakamotosan | 避免做作，免敬 2020年3月16日 (一) 12:55 (UTC)
@痛心疾首：顺带一提，好像以前测试过新加坡的路由时，好像是走NTT的，从电信美国POP出来，转入美国NTT，跳回日本后，再跳新加坡。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月16日 (一) 13:03 (UTC)
@痛心疾首：看起来如你所说的，有人想DDOS基金会的服务器，所以数据中心的营运商用了CloudFlare的网络（是定制服务）承载（或者说防DDOS）流量，但最终处理还是基金会的机器，看上去新加坡和欧洲使用了。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月18日 (三) 00:36 (UTC)
就算考虑到keyless的话，如果不使用Cloudflare在中国的接入点，连接质量还是没保证吧。或者去元维基问下，毕竟这里只不过基金会的托管站，这样根本性的部署调整始终绕不开的。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月15日 (日) 02:00 (UTC)
Cloudflare的个人版CDN会插入他们的Cookie，不知道商业版能否关闭。--泡泡小号028（留言） 2020年3月15日 (日) 05:34 (UTC)

路由调整

最新留言：在4年前发布3条留言2人参与讨论
  • 中国电信至新加坡、荷兰、旧金山三个节点不再经Cloudflare的网络承载（如果需要经Cloudflare网络，必须通过中国电信北美的公共POP出去）。也就是按往常路径，各走各路。
    • 新加坡节点会从日本的POP出去，通过NTT承载到新加坡的流量，这样就不用“环太平洋游”了。当然考虑到中国电信经NTT到日本的流量质量嘛……
  • 中国电信与zayo的连接仍然要绕欧洲。

承接“请问维基百科是何时被封IP的？”的讨论。——路过围观的Sakamotosan | 避免做作，免敬 2020年4月7日 (二) 06:27 (UTC)

可能是“钱实在是太多了”（前面就提过，基金会的DC被人打，所以订了这款特殊服务。应该是为了让CF来做透明清洗？）——路过围观的Sakamotosan | 避免做作，免敬 2020年4月20日 (一) 02:16 (UTC)

美国旧金山的图片服务器 198.35.26.112 可能被封锁

最新留言：在4年前发布4条留言4人参与讨论

用Accesser访问时发现无法载入图片，是upload.wikimedia.org无法连接，ping时域名解析正确，但显示连接超时。hosts改成新加坡的图片服务器后可以正常访问。 Whatsok（查·论·献） 2020年4月13日 (一) 14:12 (UTC)重庆中国联通

我这里图片显示是正常的，不过我用的二级运营商经常莫名其妙地就连接超时打不开了，估计是网络出口拥堵了，要等一等。--侧耳倾听 2020年4月16日 (四) 06:08 (UTC)
广东和重庆联通trace和tcp没发现问题。广州电信端口通，也没发现加载问题，不过端口的确偶然超时。可能真是出口拥堵。——路过围观的Sakamotosan | 避免做作，免敬 2020年4月16日 (四) 06:25 (UTC)
说的好像就是我这里这种情况。有些网络有时连得上，有时又超时。最明显的就是 fastly 了，cloudflare 也会偶尔超时或者非常慢，upload 这个以前好像还好好的，最近是TCP连接可以建立但是等不到回应了。lilydjwg 交流 2020年4月16日 (四) 09:01 (UTC)

图片服务器已被墙

最新留言：在4年前发布4条留言3人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2020年5月21日 (四) 16:14 (UTC)。

各位维基百科人大家好：

特此报告，图片服务器（https://upload.wikimedia.org/ ）已经被墙。希望可以更新一下Help:如何访问维基百科#IPv4连接报表里面的“图片服务器”一栏的连接勾勾。谢谢。

--162.211.224.40（留言） 2020年5月9日 (六) 17:05 (UTC)

请看附属说明。单纯的 https://upload.wikimedia.org/ 是会被301到C区，而C区等没修正地址的确是有问题的。但通过图片访问的还是upload专用的地址，同样地upload 301之前的地址也是upload专用的地址，那个暂无发现问题。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月11日 (一) 01:29 (UTC)
感谢cwek回复。我终于弄明白了。比如这个网址：https://upload.wikimedia.org/wikipedia/commons/3/37/Mud_Cow_Racing_-_Pacu_Jawi_-_West_Sumatra%2C_Indonesia.jpg 没有被墙。但是单单访问https://upload.wikimedia.org/ 是会被301到C区，而C区被墙。 162.211.224.40（留言） 2020年5月11日 (一) 14:45 (UTC)

现在hosts和DoT都已失效

最新留言：在4年前发布2条留言2人参与讨论

GFW可以执行SNI阻断，只能望Wikipedia提供ESNI功能。 奥田95（留言） 2020年6月8日 (一) 10:24 (UTC)

目前ESNI属于草案（即实验性功能），故支持此功能的希望渺茫。您可以通过本地反代或非直接连接的方式（如：镜像网站）继续访问维基百科。 --安忆Talk 2020年6月20日 (六) 05:48 (UTC)

新加坡节点被墙

最新留言：在4年前发布36条留言8人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：Jimmy-bot（留言） 2020年6月24日 (三) 16:14 (UTC)。

昨天晚上发现无法访问新加坡节点，站长之家ping测试发现中国大陆探测点几乎全部超时。5月20日晚间有一段时间也这样，不过持续时间没有多久又恢复了。--🔨（留言） 2020年5月23日 (六) 01:48 (UTC)

先挂节点报废吧。感觉是不是滥用了SNI缓存机制导致被盯上了？——路过围观的Sakamotosan | 避免做作，免敬 2020年5月23日 (六) 02:47 (UTC)
而且两会、国安法加料版、6月活动临近，不可猜透啊。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月23日 (六) 02:48 (UTC)
毕竟新加坡节点相对于其他的节点有距离上的优势。--🔨（留言） 2020年5月23日 (六) 04:37 (UTC)
upload-lb也被ko了，103.102.166.240ping了半天ping不通。--Liuxinyu970226（留言） 2020年5月23日 (六) 08:37 (UTC)
更准确来说，是新加坡DC的地址段都block（因为连test这个近乎不公开的入口也在骨干没了）。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月23日 (六) 14:01 (UTC)
然后在电信广州节点上跑了一下tcp的traceroute，结果发现：只需要5跳就到了，而且延迟和过了海几乎一样………………如果对中国互联网架构理解的话，请想一下5跳应该去到哪里。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月23日 (六) 14:11 (UTC)
初步探测：3个443入口5跳接通，然后同网段其他地址理论上ping的通，有开端口的也syn的通，而且跳数基本正常。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月23日 (六) 14:19 (UTC)
@Cwek：可为什么tcping新加坡IP却能通呢？Probing 103.102.166.224:80/tcp - Port is open - time=202.008ms --Liuxinyu970226（留言） 2020年5月30日 (六) 00:45 (UTC)
用tcp的traceroute检查下跳数，低于一定跳数你想下这会多可怕。port open只代表tcp三次握手成功，但是如果数据传输行为不正常那就是另一回事。希望这只是短暂现象。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年5月30日 (六) 00:48 (UTC)
今天偶然试着用站长之家ping了新加坡节点，发现已经可以ping通。因为好一段时间没去测所以不知道什么时候恢复的，从Help:如何访问维基百科的编辑历史来看可能是5月30日或之前。--🔨（留言） 2020年6月5日 (五) 13:32 (UTC)
嗯，我也试了一下新加坡节点又能用了，所以能不能求情把ulsfo的IPv4也给解封？哪怕这会导致所有zh.wiki啥的.org全被SNI墙我也忍了，毕竟访问C区的话新加坡节点速度甚至不如荷兰的那个--Liuxinyu970226（留言） 2020年6月6日 (六) 01:11 (UTC)
唉，又不能用了，而且eqiad是不是也挂了？所以现在墙究竟在搞啥啊？故意让我各种ping通又封我hosts？--Liuxinyu970226（留言） 2020年6月6日 (六) 03:12 (UTC)
……不想和半吊子讨论这些问题了。简单就是，测一下tcp的traceroute。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月6日 (六) 03:26 (UTC)
@Cwek：你叫我怎么测出“5跳就通”，我这边除了某些超时结果，前12跳全是10.几的内网IP地址。--Liuxinyu970226（留言） 2020年6月6日 (六) 04:49 (UTC)
好吧，我测试的环境1跳就能入接入网了，平均在2~4跳进入骨干网。或者应该说“从进入接入网后，2~4跳，也就是5跳开始”，如果很快就遇到目标地址，肯定有问题。到国外地址，从接入网开始，平均在9~10跳及以上。PS.为啥你的测试环境这么多跳内网地址。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月6日 (六) 05:33 (UTC)
回正题，感觉是路由黑洞的延伸。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月6日 (六) 05:41 (UTC)
@Liuxinyu970226 恕我孤陋寡闻，但是好像所有zh.wiki啥的.org已经全被SNI墙了。162.211.224.40（留言） 2020年6月9日 (二) 13:59 (UTC)
@162.211.224.40：不不不，只有维基百科和中文维基语录被照顾而已，其他的都是ulsfo的锅。--Liuxinyu970226（留言） 2020年6月11日 (四) 01:16 (UTC)
哦，明白了。其它的维基媒体项目只是被DNS污染，并没有被SNI照顾。你所说的“ulsfo的锅”指的是什么？162.211.224.40（留言） 2020年6月11日 (四) 12:02 (UTC)
指的是ulsfo的节点（198.35.26.96）被封锁的事情。--🔨（留言） 2020年6月12日 (五) 06:23 (UTC)
哦，明白了。多谢说明。162.211.224.40（留言） 2020年6月12日 (五) 21:04 (UTC)
最近初测来看，eqiad和eqsin的icmp包路由行为正常（跳数符合预期，包括ping和traceroute），但tcp包的路由行为异常（跳数不符合预期，三次握手看上去没问题，但是发送数据后不会有响应）。如果非要求个心理安慰的话，根据DC命名规则，这两个DC是租赁Equinix的DC的。  囧rz...——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月12日 (五) 07:37 (UTC)
也就是说美国阿什本和新加坡这两个数据中心都是租赁Equinix公司的数据中心，而Equinix公司的数据中心的服务器现在正在被墙TCP重点关照，所以维基媒体设在Equinix公司的数据中心也就被TCP躺枪了？162.211.224.40（留言） 2020年6月12日 (五) 21:04 (UTC)
如果出于心理安慰的话，可以这么想。虽然好像记得最开始测定时没发现eqiad有这个问题，而且服务器是租赁的，但是对应的地址段都是基金会自有的（也就是在DC的接入线路上宣告路由），并在同一个AS里面，实际上如果对同一个AS做同样的事，一个都逃不掉。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月13日 (六) 02:37 (UTC)
都封到这个份上了，还是不上IP地址封杀。而且维基媒体所有的项目的IP地址就那么几个。墙果然不是逻辑可以理喻的。162.211.224.40（留言） 2020年6月13日 (六) 13:02 (UTC)
ESNI一来，保准全部IP都会封掉，当然，也不排除ESNI来之前IP就已全被封的可能性。--🔨（留言） 2020年6月13日 (六) 13:15 (UTC)
严重同意!!!!!!!!!!!!!! 66.241.128.130（留言） 2020年6月13日 (六) 14:42 (UTC)
@Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 “AS”在这儿指的是Autonomous System自治系统吗？162.211.224.40（留言） 2020年6月14日 (日) 13:06 (UTC)
我认为不是被墙了，而是新加坡节点其自身的网络出了问题，因为我手里的香港服务器也会出现连接超时的情况。如讨论中所说，阿里云和其他服务商的不同服务器都出现了连接维基新加坡服务器[2001:df2:e500:ed1a::1]及103.102.166.224超时的情况。这显然是上游的问题。 --安忆Talk 2020年6月26日 (五) 00:25 (UTC)
(～)补充：是直接访问网页的HTTP 504超时（即TCP），不是Ping IP。 --安忆Talk 2020年6月26日 (五) 00:29 (UTC)
我看不懂你在说什么。能收到 HTTP 504自然是TCP没有问题。我刚测试的结果，ICMP 和 TCP 80 都没有问题，TCP 443 握手成功，但当客户端发出Client Hello开始TLS握手的时候开始丢包。另外mtr -T -P 443 103.102.166.224显示，数据包在进入联通骨干网之前就被回复了（没出省级网络）。看上去跟上次GitHub等被中间人的时候挺类似，只是没能等到伪造的回复。194.50.170.206（留言） 2020年6月26日 (五) 05:21 (UTC)
我也看不懂你在说什么。你是怎么得出能收到HTTP 504就是TCP没有问题的结论的？你是“用户-维基新加坡节点”直接连接，而我是使用每时每刻都在与维基新加坡节点进行通信的、香港PCCW网络的香港服务器反代维基新加坡节点，连接全程是“用户-香港服务器-维基新加坡节点”，香港难不成也有墙？用户看到的504 Gateway Timeout是由我的服务器发出的，表示的是“香港服务器-维基新加坡节点”这段超时。服务器的错误日志为[error] upstream timed out (110: Connection timed out) while SSL handshaking to upstream, upstream: "https://103.102.166.224:443"。这按照你的逻辑当然是TCP没有问题，毕竟又不是不能用。提醒你一下，“能用”和“用起来稳定”是两个概念。我上一条回复的意思概括起来是“我认为新加坡节点这段时间自身网络有问题，因为在非中国大陆的网络下连接它也会出现连接超时的情况，故无法断言是被墙了。” --安忆Talk 2020年6月26日 (五) 09:15 (UTC)
哦，原来你看到的504 Gateway Timeout不是维基媒体服务器发出的啊……那你说它干嘛呢。你这也是TLS握手出问题啊，跟我观察到的一样。mtr跟一下呗。我连省网都出不去，所以显然我这里在省级就被墙了（或者省级网络故障）。194.50.170.206（留言） 2020年6月26日 (五) 11:23 (UTC)
因为我和上游服务器出现了连接超时的情况才会向前端发504啊，又因为用的不是大陆网络，所以我才会说“可能不是被墙了，而是新加坡节点其自身的网络出了问题”，你捋一捋思路……刚刚mtr了一下，数据包从he.net的BGP路由出来后（我有直接的he.net）就到了14907.sgw.equinix.com转而到了text-lb.eqsin.wikimedia.org，我这里的连接不经过国内运营商的骨干网，但还是时不时地请求超时，所以我猜测可能是eqsin自己的问题。不过这也没法解释你在国内也出现了类似省级网络故障的情况…… --安忆Talk 2020年6月26日 (五) 12:33 (UTC)

本地反向代理没有自行签发、导入证书的必要

最新留言：在4年前发布7条留言3人参与讨论

Help:如何访问维基百科#本地反向代理一节所描述的方法似乎过于繁琐。如果仅仅是想访问本站，普通的反向代理就够了。以httpd为例，如果你想从浏览器透过sslproxy.example.com:8088这个虚假的网址访问中文维基的话，只需将"127.0.0.1 sslproxy.example.com"本身加入hosts文件，然后在httpd的配置文件里添加以下内容： 

<VirtualHost *:8088>
    DocumentRoot "${SRVROOT}/htdocs"
    ServerAlias sslproxy.example.com
    RequestHeader set Host zh.wikipedia.org
    SSLProxyCheckPeerName off
    ProxyPreserveHost On
    ProxyPass / h2://test2.wikipedia.org/
    ProxyPassReverse / https://zh.wikipedia.org/
</VirtualHost>

就可以了。test2.wikipedia.org可以替换成任何一个未受SNI阻断影响的姊妹计划的网址。如果你还想编辑的话，再给cookies做点手脚： 

<VirtualHost *:8088>
    DocumentRoot "${SRVROOT}/htdocs"
    ServerAlias sslproxy.example.com
    RequestHeader set Host zh.wikipedia.org
    Header edit* Set-Cookie ".wikipedia.org" "sslproxy.example.com"
    Header edit* Set-Cookie "[Ss]ecure" ""
    SSLProxyCheckPeerName off
    ProxyPreserveHost On
    ProxyPass / h2://test2.wikipedia.org/
    ProxyPassReverse / https://zh.wikipedia.org/
</VirtualHost>

之后就可以正常登录、编辑了。--Antigng（留言） 2020年7月17日 (五) 20:42 (UTC)

  • 那一节里的方法，主要是为了访问Pixiv而设计的，而Pixiv大部分资源都有来源验证。不过反代Wikipedia的话，自行签发、导入证书也有必要的（当然如果只的单纯地看看的话确实没什么必要），因为域名不对有些功能也是用不了的（如“短链接”等API就有跨域白名单）。这就导致访问服务器的域名需要是正确的，HTTPS也最好支持（HTTP反代HTTPS可能会出现其他问题）。 --安忆Talk 2020年7月18日 (六) 00:07 (UTC)
不过要说需要完善的点也是有的，一是白猫的HOSTS还不是很全，基金会用了许多明面上看不到的子域名；二是配置文件还有改善的空间，现在的也仅是“能看”而已，很多地方处理得都不是很好。 --安忆Talk 2020年7月18日 (六) 00:07 (UTC)
务必提醒一下：Firefox会拒绝自签名证书，在有HSTS的情况下导入了也没用。而Pixiv-Nginx用的证书不是自签名证书。--GZWDer（留言） 2020年7月19日 (日) 13:33 (UTC)
Pixiv-Nginx用的不是自签证书吗？是吧，它需要先安装根证书（CA），然后Nginx用的就是这个CA签发的域名证书。因为这个CA在系统里是可信的，所以这时自签的域名证书也是可信的。Firefox只是用了它自己内置的根证书列表而已，也是可以导入其他证书的。至于您说的HSTS，它只验证证书的信任链是否完整，而不是区分是不是自签的，所以只要系统或浏览器里有可信CA就可以了。 --安忆Talk 2020年7月19日 (日) 13:48 (UTC)
但是曾经试验过#使用Nginx本地反代无需代理服务器直连维基百科所述方法生成的证书Firefox不接受。--GZWDer（留言） 2020年7月19日 (日) 16:52 (UTC)
因为他只写了自签域名证书，我估计您也只弄了那个。您读读我上面对您回复的，就很容易知道，要想保证信任链的完整可信，就还需要自签CA，然后用自己的CA去签名其他域名证书。 --安忆Talk 2020年7月19日 (日) 23:12 (UTC)

路由信息更新

最新留言：在4年前发布3条留言3人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/消息。执行者：Jimmy-bot（留言） 2020年8月22日 (六) 08:14 (UTC)。

新加坡节点和阿什本节点text接入点的tcp诡异路由现象消失。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月12日 (三) 01:30 (UTC)

刚测了下，的确正常了。--🔨（留言） 2020年8月12日 (三) 07:42 (UTC)

火狐浏览器域前置修改更新

最新留言：在4年前发布1条留言1人参与讨论

各位维基人大家好：

最近有幸能够在Ubuntu 19.10上修改【最新】的火狐浏览器代码。所以更新一下2019年5月我发过的Help_talk:如何访问维基百科#修改火狐浏览器关于SNI的部分。（在Ubuntu 19.10上build火狐浏览器的具体步骤请参考[9]）

修改地方一共有两处。第一处就是2019年5月我修改的SNI代码，但是最新的火狐浏览器代码里负责生成ClientHello的源代码文件名换了（或者说是细化了），新的源代码文件名是mozilla-unified/security/nss/lib/ssl/ssl3exthandle.c。具体负责生成ClientHello的函数也换了（或者说是细化了），新函数源代码如下： 

/* Format an SNI extension, using the name from the socket's URL,
 * unless that name is a dotted decimal string.
 * Used by client and server.
 */
SECStatus
ssl3_ClientFormatServerNameXtn(const sslSocket *ss, const char *url,
                               TLSExtensionData *xtnData,
                               sslBuffer *buf)
{
    unsigned int len;
    SECStatus rv;

    len = PORT_Strlen(url);
    /* length of server_name_list */
    rv = sslBuffer_AppendNumber(buf, len + 3, 2);
    if (rv != SECSuccess) {
        return SECFailure;
    }
    /* Name Type (sni_host_name) */
    rv = sslBuffer_AppendNumber(buf, 0, 1);
    if (rv != SECSuccess) {
        return SECFailure;
    }
    /* HostName (length and value) */
    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)url, len, 2);
    if (rv != SECSuccess) {
        return SECFailure;
    }

    return SECSuccess;
}

具体修改和2019年5月我公布的修改一样，修改如下两处地方： 

    len = PORT_Strlen(url);

修改成 

    len = PORT_Strlen("upload.wikimedia.org\0");

    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)url, len, 2);

修改成 

    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)"upload.wikimedia.org\0", len, 2);

注意，如果upload.wikimedia.org被SNI封杀的话，那就要更换成另外一个尚未被SNI封杀的维基基金会的SNI域名。

这一次的修改比起2019年5月的修改，多了一个要修改的源代码文件。我想既然是域前置，那就干脆做全套的域前置，包括DNS部分。所以我顺藤摸瓜的摸到了火狐负责完成DNS查询的源代码。源代码的文件名是mozilla-unified/netwerk/dns/nsHostResolver.cpp。具体负责DNS查询的函数名叫nsHostResolver::ResolveHost，细节如下： 

nsresult nsHostResolver::ResolveHost(const nsACString& aHost,
                                     const nsACString& aTrrServer,
                                     uint16_t type,
                                     const OriginAttributes& aOriginAttributes,
                                     uint16_t flags, uint16_t af,
                                     nsResolveHostCallback* aCallback) {
  nsAutoCString host(aHost);
  NS_ENSURE_TRUE(!host.IsEmpty(), NS_ERROR_UNEXPECTED);

  nsAutoCString originSuffix;
  aOriginAttributes.CreateSuffix(originSuffix);
  LOG(("Resolving host [%s]<%s>%s%s type %d. [this=%p]\n", host.get(),
       originSuffix.get(), flags & RES_BYPASS_CACHE ? " - bypassing cache" : "",
       flags & RES_REFRESH_CACHE ? " - refresh cache" : "", type, this));

  // ensure that we are working with a valid hostname before proceeding.  see
  // bug 304904 for details.
  if (!net_IsValidHostName(host)) {
    return NS_ERROR_UNKNOWN_HOST;
  }

  // By-Type requests use only TRR. If TRR is disabled we can return
  // immediately.
  if (IS_OTHER_TYPE(type) && Mode() == MODE_TRROFF) {

...

整个函数的篇幅巨长，所以我就不全部列出了。需要修改的是第一行： 

  nsAutoCString host(aHost);

修改成 

  nsAutoCString host("upload.wikimedia.org\0");

注意，如果upload.wikimedia.org被DNS污染的话，那就要更换成另外一个尚未被DNS污染的维基基金会的DNS域名。

祝墙内的各位维基人在魔改火狐浏览器以后，免翻墙域前置浏览维基百科快乐！

--不爱思考得猪（留言） 2020年9月8日 (二) 02:31 (UTC)

www.jinzhao.wiki疑似被屏蔽

最新留言：在4年前发布3条留言3人参与讨论

近期"www.jinzhao.wiki"在中国大陆无法正常访问，疑似遭到TCP重置攻击(浏览器提示连接重置) Asanatsa（留言） 2020年10月20日 (二) 13:53 (UTC)

我这里可以访问。移动端访问chi.jinzhao.wiki会错误地重定向至zh.m.wikipedia.org（正确的是chi-m.jinzhao.wiki)，可能是您觉得无法访问的原因。 --安忆Talk 2020年10月20日 (二) 14:34 (UTC)
镜像站的问题，别再这里问。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年12月8日 (二) 05:47 (UTC)

关于2020年12月IP封锁的新一轮问题分析

最新留言：在4年前发布3条留言3人参与讨论
  • 首先，5个地址的tcptrace都是没问题的。（没错包括旧金山）
  • SNI阻断似乎可以针对特定地址的，因为根据SNI的原理，突发奇想，在Google随便找了一个https的网站，解析域名对应的服务器IP（whois过，IP也是国外的），然后替换掉测试IP。起初假设会在客户端握手就断掉，但是却收到服务器的响应（只是域名不匹配报错），然后也用upload5个IP测试，除了阿什本，都是能收到服务器响应（tls层连接匹配，但http层对不上）。

结论：猜不透。 （笑 ——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年12月8日 (二) 06:05 (UTC)

其实我觉得可以将页面3.2章节去掉…因为现在的情况下，受限于SNI识别（范围应该会逐渐扩大并成为主流），即使IP正常也没什么作用。以下是离题内容：
我认为本地伪造SNI或者不发送SNI也不是什么太好的办法，毕竟要取决于服务端的处理方式，说不定WMF哪天就会将默认证书换成其他的或者干脆拒绝不提供正确信息的连接了。目前看来，最好的办法就是尽量有VPN就用VPN，其次是如果技术够或者爱折腾的话就用本地反代之类的东西（直连IP体验不怎么好，间歇性抽风或者巨慢），再次就是各种MITM式的第三方反代（会有安全和隐私问题），最后就是只读离线数据库。--安忆Talk 2020年12月8日 (二) 06:42 (UTC)
这问题11月就有了，记得那个时候@Liuxinyu970226就在这笔编辑里进行了反馈。--🔨（留言） 2020年12月8日 (二) 11:41 (UTC)
检索自“https://zh.wikipedia.org/w/index.php?title=Help_talk:如何访问维基百科/存档2&oldid=79363299”
返回到“如何访问维基百科/存档2”页面。