Help talk:如何访问维基百科

维基百科,自由的百科全书
跳到导航 跳到搜索

Opera浏览器也可用于访问维基百科[编辑]

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

198.35.26.96疑似被封IP[编辑]

请求已拒绝 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)

存在意义???[编辑]

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

  • 有镜像网站,看得到的也可以参照这个帮助看不到的人。怎么就没意义了? --🐕🎈(实用主义大于天) 2018年8月6日 (一) 02:46 (UTC)

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

DNS over HTTPS[编辑]

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

H:VISIT[编辑]

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

  • 你住在中华人民共和国,但是现在在国外留学,然后你放假了要回国,这个页面就教你怎么在国内也能登录维基百科。大概是这样吧,我扯不下去了。--Tazkeung(CommentHERE) 2018年8月2日 (四) 05:55 (UTC)
  • 既然进去了说明能上维基百科,看怎么上没意义,进不去说明上不了,上不了也不可能进去,看不到Skywalker is gone 2018年8月2日 (四) 05:56 (UTC)
    • 已經上的用戶教不能上的用戶,但又不完全清楚方法時。吉太小唯Don't Say Lazy.TALK) 2018年8月2日 (四) 06:07 (UTC)
    • 虽然可能没有什么用,但是在此只要大喊F*ck GFW就对了。--Super Wang ~~邀您关注每周翻译~~ 2018年8月2日 (四) 07:31 (UTC)
解决直连或者申请在代理上豁免的需要。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月2日 (四) 12:50 (UTC)
  • 便于转载。便于勉强查看(缓慢代理、特定网络等)时了解有关方法。便于记录有关与最新信息。--YFdyh000留言) 2018年8月2日 (四) 17:52 (UTC)
  • 可以从能访问的维百镜像上的这个页面找到访问方法,当时198.35被墙的时候就是这样做的Face-smile.svg--BR 2018年8月3日 (五) 11:53 (UTC)
  • 哈哈哈哈哈哈哈我早就想到这个了……“我上不去维基怎么办?”“看看Help:如何访问维基百科啊”……哈哈哈哈容我再笑会儿……718smiley.svg--正在学习友谊就是魔法CuSO4 2018年8月3日 (五) 13:15 (UTC)
    • 笑笑无妨。--希望自己谦逊的HB 2018年8月5日 (日) 12:35 (UTC)
  • 怎么了?有镜像啊,能直接访问的人也可以参照那个给不能访问的人帮助。哪里可笑? --🐕🎈(实用主义大于天) 2018年8月6日 (一) 02:46 (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)
[2],似乎部分地区的确解封了(但最近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)
  • 移动4G、宽带hosts法均已失效。地理位置广东。—YouTable 2018年8月25日 (六) 04:04 (UTC)
  • 时断时续,断了以后需要从其他语言版本重新点入--苞米() 2018年8月25日 (六) 04:06 (UTC)
  • 我从今天开始直接按浏览器的收藏(书签)进入中文维基百科有时会失败,但是通过选择语言的界面进入倒是没问题。--FishPlusWolf 2018年8月25日 (六) 13:40 (UTC)
  • 这个“解封”应该是启用了IPv6的缘故吧,然而IPv4下反而封得更紧了,改了Hosts都能“连接被重置”,一首凉凉送给大家。--侧耳倾听 2018年8月25日 (六) 16:58 (UTC)
  • Hosts已经不管用了=-=,现在必须X墙 MasaneMiyaPA留言) 2018年8月26日 (日) 08:44 (UTC)
  • 烦请墙内Wikipedians(特别是汇报hosts被封)查看一下是否可以浏览其它语种的维基百科。如果可以的话,那将是第一次目睹墙SNI封杀。(因为维基百科所有子域都使用*同样的*证书,所以墙是不可能通过证书来进行有选择性封杀的)69.42.179.19留言) 2018年8月28日 (二) 14:38 (UTC)
  • 又。。。这两天的事--Qa003qa003留言) 2018年8月30日 (四) 01:40 (UTC)
  • 大約兩個月前,我會內地還能用日文維基與英文維基,大約一個月前,日文維基就被封禁了,而中文維基一直維持在封禁狀態(包括粵語版)Pigppp留言) 2018年9月1日 (六) 16:37 (UTC)

Hosts失效[编辑]

目前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了,在此之前,只有GoogleFacebookTwitter等巨头网站才有这样的待遇,看来自今年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)
    • 有什么浏览器支持域前置(Domain Fronting)吗?由于英文维基不受影响,用 $ curl -s https://en.wikipedia.org/wiki/Wikipedia:VP -H "Host: zh.wikipedia.org" 的方式可以有效的访问中文维基,并且使用的是自己的IP,故不会受到IP封禁的影响。——Arnie97留言) 2018年8月25日 (六) 16:22 (UTC)
    • IPBE的申请本来就没什么门槛。——星耀晨曦留言) 2018年8月25日 (六) 23:21 (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)
        • 要看CDN商的反应,不过应该难度不大?因为CDN本身就要根据访问来控制DNS解析,其有能力和需要去这样干。实现方法要么增加字段,要么使用txt兼容。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月29日 (三) 06:12 (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,试了一下似乎不可行[3]?需要服务器端配合?--百無一用是書生 () 2018年8月29日 (三) 09:54 (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)

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

使用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本地反代无需代理服务器直连维基百科[编辑]

DNS的疑问[编辑]

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

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

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

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

為甚麼Help:如何访问维基百科m:Help:如何访问维基媒体旗下项目裡提供的網址有問題[编辑]

為甚麼text-lb.(資料中心名).wikimedia.orgupload-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都被屏蔽了[编辑]

昨天(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)

能不能在IIS上搭建反向代理[编辑]

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

GFW在测试新功能???[编辑]

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

  • @Whisper of the heart:有同样问题,不过我用的是1.1.1.1的DoH,现在只有科学上网了。。。(一开始我还以为1.1.1.1挂了)-- by  ✉  DW  at 2019年3月23日 (六) 19:09 (UTC)
    • @DW_YoungDLS:我又多试了几次,坚持直连的话也不是不可以,最终总会成功的,不过过程挺折磨人,能科学上网的话体验肯定更好。--侧耳倾听 2019年3月24日 (日) 13:06 (UTC)
  • 会话保存机制有点取巧,你很难保证上完en后还是用回en的TLS链接连接zh,这样还是会遇到SNI RST。——路过围观的Sakamotosan | 避免做作,免敬 2019年3月24日 (日) 02:06 (UTC)
  • 现在是有间歇性中断,所有专案都会卡断。没有有效大型支援的话,根本无法抗衡这些动作。——約克客留言) 2019年3月24日 (日) 04:48 (UTC)
  • 这已经很久了其实,见WP:如何访问维基百科 --------来自一个 温暖的胖子 ,还有,User:胡葡萄 是我的搭档! 2019年3月26日 (二) 16:38 (UTC)
    • @橙子木:这次的情况又不一样了,以前是开一下英文维基百科就可以了,这次是开了中文维基百科后连着英文维基都会被重置,需要等一段时间才能继续。--侧耳倾听 2019年3月31日 (日) 02:16 (UTC)
      • @Whisper of the heart:你描述的问题我记得我今年1月份就已经间断观测到过--------来自一个 温暖的胖子 ,还有,User:胡葡萄 是我的搭档! 2019年3月31日 (日) 14:51 (UTC)
  • 咋没人来讨论呢,难不成都是用VPN的翻墙党?--侧耳倾听 2019年3月31日 (日) 03:14 (UTC)
    • 不建议利用握手缓存访问zhwp,早在刚刚上SNI的时候我也试过,但是发现提交编辑很难,所以我很早就放弃了。另外,墙也不是不知道有这种操作。现在我电脑用本地反代大法,手机用VPN。--№.N留言) 2019年4月2日 (二) 00:39 (UTC)
  • 我也遇到了。另外现在 GFW 确实有所变化,Google 的 IP 封了不少。--石𫁶留言) 2019年3月31日 (日) 09:36 (UTC)
    • 顺带一提,这段时间中国电信 IPv6 的对外通信也有中断,虽然恢复了因此不能绝对确定与墙有关便是……--石𫁶留言) 2019年3月31日 (日) 09:37 (UTC)
    • 那么我认为还是等基金会上 TLS 1.3 才比较保险。--石𫁶留言) 2019年3月31日 (日) 09:39 (UTC)
  • 其实真的想要不挂代理稳定上维基的话,推荐本地反代(可正常登陆编辑)。但是性能波动大,有时比代理快,有时比代理慢,我个人是在代理失效的情况下使用的。(GitHub上有人发布了现成的)--☣甲乙丙丁戊留言) 2019年4月4日 (四) 03:31 (UTC)
    • 这个倒也可以哦。--侧耳倾听 2019年4月4日 (四) 08:36 (UTC)

英文维基百科疑似被DNS污染[编辑]

今天(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:如何访问维基百科中的无效方法[编辑]

去年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.BANxSUser: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的部分[编辑]

以下是火狐浏览器源代码中关于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)

半突发新闻[编辑]

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

维基媒体域名被DNS污染了吧,如mediawiki.orgwikidata.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)