维基百科
Help talk:如何访问维基百科/存档2
| Help_talk:如何访问维基百科/存档2的页面中的文本或其他内容在2023年10月14日 (六) 15:57 (UTC)被复制粘贴移动到Help:如何访问维基百科/Firefox浏览器补丁。先前页面的历史现归属于目标页面，且在目标页面删除前不得删除。 |
各位觉得维基百科中文版政策是不是该宽松些？
如题。维基百科中文版在大陆已被封锁，诸位可能有些居住在大陆之外吧？
可是我们大陆用户不可能每天都花大功夫破网，结果却发现ip被封禁！！！而且破网的话网速必然会慢，等待加载半天却发现ip被封禁！！！好痛苦的感觉！！
我几乎没有什么编辑，但我衷心喜爱维基百科。看着被封杀的维基百科一天天堕落了不甘心，哎！
维基百科能不能给大陆用户一点方便，解禁一些ip?毕竟很少人买VPN用来泡维基，我想我们都是看到了随手改一改啊
要么我，，也去申请ip解禁可以么？ 重点是都被封禁了，想尽可能免费来访问也不容易，实在不想反复寻找ip段外的破网软件了！这么麻烦谁会来维基百科呢？这么麻烦谁会编辑呢？
手机速打，不胜其烦。我可能有些过激，还望各位多多包涵！
Talkative Sun 2016年8月21日 (日) 09:23 (UTC)
- (－)反对，开放代理给维基百科带来巨大的麻烦，而且我们给需要的用户提供了WP:IPBE权限。--Antigng（留言） 2016年8月21日 (日) 09:31 (UTC)
- @Antigng：手机上能设Host吗？--4Li 2016年8月21日 (日) 09:35 (UTC)
- 估计是用的代理某个地址还没被我们封禁...--Antigng（留言） 2016年8月21日 (日) 09:36 (UTC)
- 请问您如何访问？当您的ip被封禁后如何申诉？Talkative Sun 2016年8月21日 (日) 09:38 (UTC)
- 发邮件到unblock-zh@wikimedia.org啊。--Antigng（留言） 2016年8月21日 (日) 09:39 (UTC)
- 人人可编辑的百科全书去了哪里？Talkative Sun 2016年8月21日 (日) 09:40 (UTC)
- @Antigng：您说的很对，我看了很久才发现没被封禁的IP。但我觉得大部分用户不会有这么耐心，为了编辑又发邮件又来讨论，不是吗？Talkative Sun 2016年8月21日 (日) 09:43 (UTC)
- 致樓主：禁止開放代理是全域政策，本地只能遵守。詳見：请勿使用开放代理--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 09:49 (UTC)
- @Antigng：您也曾经是ip用户，时间也颇长，一定深切意识到这种编辑的简便性。不能说让所有人都申请豁免吧！刚才的ip用户说的有道理，不能全是管理员等在中文维基百科上，不能否定代理服务段ip用户的作用！Talkative Sun 2016年8月21日 (日) 10:19 (UTC)
- 我一直是改hosts编辑的哦......--Antigng（留言） 2016年8月21日 (日) 10:21 (UTC)
- @Antigng：所以我有时多管闲事么。IP用户怎么办？不知道hosts的用户怎么办呢？多一事不如少一事！维基百科就是方便快捷的编辑吸引人啊！繁琐的处理谁来编辑！Talkative Sun 2016年8月21日 (日) 10:26 (UTC)
- 我们有Help:如何访问维基百科。不认为会有多少用户懂VPN/proxy不懂hosts。--Antigng（留言） 2016年8月21日 (日) 10:27 (UTC)
- 我打开手机上维基方便还是root再配置host方便？众所周知，最简单的是最好的Talkative Sun 2016年8月21日 (日) 10:38 (UTC)
- (＋)支持不说了，建议是适当宽松！！！不能否定代理段ip用户的作用！Talkative Sun 2016年8月21日 (日) 10:19 (UTC)
- (＋)支持同上，维基需要更多编辑，现在中文维基还是相当紧张的。hosts好多人都表示太慢，虽然我没发觉，但是要特殊情况特殊处理。如果觉得怕麻烦，台湾香港说明也来封禁维基百科吧，这样子可以有效减少破坏者，嗯？--晴空·和岩 讨论页·反互煮·协作计划 2016年8月21日 (日) 10:23 (UTC)
- 即使没有防火长城，合适代理服务器总是可以起到加速作用，如此说来，在任何一个语言的维基百科都没有必要封禁代理服务器，又如何会有此全域方针？--Antigng（留言） 2016年8月21日 (日) 10:26 (UTC)
- 如果有台湾香港用户严重破坏，由于他们的IP地址会被服务器暂时保存3个月，这段时间内查核员就会找出他们使用的IP段并封禁。由于IP相对于地理位置比较固定，不需要封禁所有的港/台IP。然而对于代理服务器情况就不一样了，有了代理服务器，任何破坏者都可以足不出户地让自己的IP出现在地球的任何一个角落。--Antigng（留言） 2016年8月21日 (日) 10:34 (UTC)
- @Antigng：您未免太患得患失了。Talkative Sun 2016年8月21日 (日) 10:38 (UTC)
- 不是我患得患失，你可以看看Category:Dsfsswec的維基用戶分身和Category:Πrate的維基用戶分身这两个分类里面所有用户的所做所为。阻止他们破坏的唯一方法就是封禁代理服务器。--Antigng（留言） 2016年8月21日 (日) 10:41 (UTC)
- @Antigng：那看来这个工程很艰巨，我刚刚在手机端用的HK代理不就没封掉么？现在大陆不通过一些手段无法访问，谁会来搞破坏！Talkative Sun 2016年8月21日 (日) 10:51 (UTC)
- 完了完了。早知道就噤声，又被封了一个IP……Talkative Sun 2016年8月21日 (日) 10:58 (UTC)
- 且不论“大陆用户不会用代理搞破坏”其实不成立（你可以看看[1]和Special:用户贡献/103.41.132.29），即使这个命题成立，大陆用户不会用，不代表港台用户不会。除非让那些代理服务器提供商主动跟wmf联系，让他们正确设置XFF请求头，否则就没有不封禁的理由。--Antigng（留言） 2016年8月21日 (日) 11:00 (UTC)
- @Antigng：您未免太患得患失了。Talkative Sun 2016年8月21日 (日) 10:38 (UTC)
- 如果有台湾香港用户严重破坏，由于他们的IP地址会被服务器暂时保存3个月，这段时间内查核员就会找出他们使用的IP段并封禁。由于IP相对于地理位置比较固定，不需要封禁所有的港/台IP。然而对于代理服务器情况就不一样了，有了代理服务器，任何破坏者都可以足不出户地让自己的IP出现在地球的任何一个角落。--Antigng（留言） 2016年8月21日 (日) 10:34 (UTC)
- 即使没有防火长城，合适代理服务器总是可以起到加速作用，如此说来，在任何一个语言的维基百科都没有必要封禁代理服务器，又如何会有此全域方针？--Antigng（留言） 2016年8月21日 (日) 10:26 (UTC)
长者说过：闷声大发财，这是最好的。其实也是有些没有被封的代理的发现了就拿去续一秒。对了某维基QQ群不是有管理员发IPBE吗。--20160821ax（留言） 2016年8月21日 (日) 11:03 (UTC)
- 不止是QQ，IRC，telegram上面都有中文维基百科频道，每个频道都有管理员长年驻守，你跟他们说都会授权。--Antigng（留言） 2016年8月21日 (日) 11:13 (UTC)
- 註：IRC頻道：#wikipedia-zh connect、Telegram群：@wikipedia_zh。-和平、奮鬥、救地球！（留言） 2016年8月21日 (日) 12:50 (UTC)
- @Antigng：大陆恐怕打不开irc，速度也太慢了……Talkative Sun 2016年8月21日 (日) 14:56 (UTC)
- 至於IP用戶破壞，我有一個提案，IP用戶編輯時要求輸入1到12位驗證碼，不知道怎麼樣。—John Doe 120（talk） 2016年8月21日 (日) 12:51 (UTC)
- 我只会选择利于发展维基的道路，支持不会更改。--晴空·和岩 讨论页·反互煮·协作计划 2016年8月21日 (日) 13:29 (UTC)
- 此問題在本地社群沒有討論餘地，即使本地100%支持寬鬆化也不能修改，但可以去meta提案看看。再和各位重複報告一次，維基百科從來不是民主實驗場，所有的方針與指引創設的初衷都不是讓這裡更民主。禁止開放代理政策是全維基計畫都通用的，而基金會從來沒阻擋過中國大陸維基人訪問他們的網站，基金會阻擋的是開放代理。被封的代理，港台維基人同樣也不能使用--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月22日 (一) 00:17 (UTC)
- 请自行购买/架设翻墙工具，不要用免费的--百無一用是書生 (☎) 2016年8月22日 (一) 01:49 (UTC)
- Shizhao，别逗了，我用了收费VPN，不也一样封VPS段？一句话，没正确贯彻NOP和xff设计要求的，呵呵，祝好运，或者死死地气设hosts或者申请IPE。——路过围观的Sakamotosan 2016年8月22日 (一) 07:06 (UTC)
- 呵，我算是明白了。原来是变相收费。能不能参考特殊国情！我也算是服了。宽松宽松就行了。又不要您纵容！过几天全封了看看大陆还有多少用户吧！Talkative Sun 2016年8月22日 (一) 02:50 (UTC)
- 这孩子终于开始疯了，めでたし、めでたし。——路过围观的Sakamotosan 2016年8月22日 (一) 07:06 (UTC)
- “中文维基百科”不等于 “两岸四地维基百科”，也不等于“中华人民共和国维基百科“。事实上，无论是编者还是读者，即使在没有封锁的时间里，港澳台用户也占了大头。--Antigng（留言） 2016年8月22日 (一) 03:22 (UTC)
- 大家誤會了。白話講：此事輪不到本地社群決定，更不由管理員決定，要罵請罵基金會和吉米·威爾斯。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月22日 (一) 04:03 (UTC)
比較
- 各位觉得维基百科中文版政策是不是该宽松些？
- 各位覺得中國網路過濾機制是不是該對维基百科中文版宽松些？
我的答案：
- 沒必要，且維基百科中文社群已有Wikipedia:IP封禁例外的作法，是不是對中國網路過濾機制受惠/害地區有宽松些呢？好像有。
- 有必要，中國網路環境和生態已不是十年前，應該有自信面對 维基百科中文版 的內容、實踐、及生態。
--❦‽研究及來源 hanteng✉ 2016年8月22日 (一) 09:12 (UTC)
- 反对封禁维基，但反对“中國網路環境和生態已不是十年前”一句，我觉得中国那群键盘侠从没消停过，网民素质也有待提高。--晴空·和岩 讨论页·反互煮·协作计划 2016年8月22日 (一) 10:20 (UTC)
- 這篇文章意思是，開放代理不應該自動地被禁止，與meta的文章標題相衝突。還有，關於代理的文章，中文版本比較落後，只翻譯了一部分。—John Doe 120（talk） 2016年8月27日 (六) 13:20 (UTC)
- 「開放代理不應該自動地被禁止」????我讀了半天怎麼覺得相反？它是說在大多數情況下，不應該無限期封禁開放代理，因為代理的IP可能會被重新分配，無論如何不因單一事件而無限期封禁特定IP段。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月27日 (六) 13:39 (UTC)
- --Antigng（留言） 2016年8月27日 (六) 15:23 (UTC)“Open proxies may be blocked on sight according to the policy on open proxies. The IP should be unblocked once the proxy has been closed. Because the IPs may eventually be reassigned or the proxies closed, blocks should not be indefinite, but in some particular cases can be very long term. Block lengths should typically range from several weeks for dynamic IPs and short term Tor nodes, up to several years for long term proxies hosted on static IP addresses.
Administrators who block open proxies should attempt to record in the block log or on the user talk page how to verify whether the IP address is still an open proxy at a future date. Administrators who deal with unblock requests from blocked open proxies should typically seek advice from either the blocking admin or the WikiProject on open proxies before unblocking.”- 閣下引原文的用意?--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月27日 (六) 16:09 (UTC)
- "Open proxies may be blocked on sight according to the policy on open proxies." 开放代理只要看到就应该封禁。--Antigng（留言） 2016年8月28日 (日) 00:35 (UTC)
- 我知道。我的問題是，閣下引原文的用意是？--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月28日 (日) 01:41 (UTC)
- 论证“開放代理不應該自動地被禁止，與meta的文章標題相衝突”不成立。--Antigng（留言） 2016年8月28日 (日) 01:46 (UTC)
- no proxy、proxy must be blocked 表示差不多的意思，no proxy、proxy may be blocked，前者表示無代理，後者表示代理有可能（但不是必須）被封禁。—John Doe 120（talk） 2016年8月28日 (日) 04:25 (UTC)
- 论证“開放代理不應該自動地被禁止，與meta的文章標題相衝突”不成立。--Antigng（留言） 2016年8月28日 (日) 01:46 (UTC)
- 我知道。我的問題是，閣下引原文的用意是？--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月28日 (日) 01:41 (UTC)
- "Open proxies may be blocked on sight according to the policy on open proxies." 开放代理只要看到就应该封禁。--Antigng（留言） 2016年8月28日 (日) 00:35 (UTC)
- 閣下引原文的用意?--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月27日 (六) 16:09 (UTC)
- 「開放代理不應該自動地被禁止」????我讀了半天怎麼覺得相反？它是說在大多數情況下，不應該無限期封禁開放代理，因為代理的IP可能會被重新分配，無論如何不因單一事件而無限期封禁特定IP段。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月27日 (六) 13:39 (UTC)
- 我看了一篇文章，它說 pt.wiki在2008-2013年對未註冊用戶的編輯，要求驗證碼，它說驗證碼對於機器人效果不佳，我認為：
- 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)
- @Talkativesun：在臺灣的國境內，任何人要逛什麼公開網路都是主權在民之臺灣國民的個人自由，美國人、日本人、德國人能逛的，臺灣人自然都能逛；北韓、中國、寮國等獨裁國家未封的，臺灣人當然也能逛，但可能沒興趣逛。從無任何臺灣的中央或地方政府機關有權或曾有權去阻止人民接近國外網站。選輸了就下台、不合全國民意就換中央政府，沒什麼好掙扎的，幹嘛要封網呢？路邊的桃李，沒說你不能摘、也沒求你摘。維基百科從未阻擋貴國人編，但也不求貴國人來編。接受世界各國人士編輯與封鎖某些具破壞性之漏洞都是維基全域的普遍通用原則，沒必要弄什麼特殊安排。如果維基基金會已表明不開放代裡，那在這裡說什麼都沒用。維基基本上未偏私任何國家，卻常出現什麼要維基改變形式或實質以遷就、適應中國單一國家的提議，但問題的根源是中國，不是維基。歧視中國人的正是貴國的獨裁政權。中國內部的問題，該由中國內部自行解決，要維基為特定國家而改變是本末倒置。--WildCursive（留言） 2016年8月23日 (二) 15:15 (UTC)
還是善意推定原則。我相信樓主是出於善意，想讓來維基百科編輯的人更多，所以希望在中文維基百科可以開特例。但很可惜不能通過，原因在樓上已說過就不重複。大家也不要怪管理員們，管理員不是萬能，他們只是忠實執行社群共識的維基人，此共識當然包括官方政策。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月23日 (二) 01:07 (UTC)
- 可不可以把申邮解封等文字突出一点，让前来编辑者更容易看清情况。还是希望特殊情况特殊处理，也别把对某党的不满全扔到我们这些小老百姓身上来撒--晴空·和岩 讨论页·反互煮·协作计划 2016年8月23日 (二) 05:19 (UTC)
- 优先介绍改hosts，除非改hosts失败或者必须依靠绳子的话而且频密编辑的话，推荐IPE。——路过围观的Sakamotosan 2016年8月23日 (二) 10:05 (UTC)
- ？？？这个投票有什么用？一万个人支持又能改变什么吗？如果投票说，咱们自己分家干吧，服务器不放佛罗里达了，不要听那什么基金会的，然后，有什么意义吗？--7（留言） 2016年8月23日 (二) 11:09 (UTC)
- 也不认同对这种事进行投票，同时认为这种事讨论不出结果。只是，中国大陆的维基早就不听基金会的了，剩下的听基金会的那几个，差不多都是把维基当“摇钱树”而已。galaxyharrylion（留言） 2016年8月23日 (二) 12:02 (UTC)
- 要不干脆独立了吧。--4Li 2016年8月23日 (二) 13:19 (UTC)
- 2、3年前就开始独立发展了，现在（或者说从那时起）打着基金会旗号的，基本上都是打着维基幌子“搞钱”的破坏份子罢了（中国大陆某些管理员）。galaxyharrylion（留言） 2016年9月3日 (六) 09:44 (UTC)
- 要不干脆独立了吧。--4Li 2016年8月23日 (二) 13:19 (UTC)
- 也不认同对这种事进行投票，同时认为这种事讨论不出结果。只是，中国大陆的维基早就不听基金会的了，剩下的听基金会的那几个，差不多都是把维基当“摇钱树”而已。galaxyharrylion（留言） 2016年8月23日 (二) 12:02 (UTC)
- 其實是發起人錯誤期待維基網站可以只針對特定地區所使用的開放代理做放鬆，這是技術上不可行的。Antigng第一次的簡要回應已經足夠「开放代理给维基百科带来巨大的麻烦，而且我们给需要的用户提供了WP:IPBE权限。」想回問樓主是否知道(1)開放代理對維基百科的治理挑戰（見请勿使用开放代理)和是否瞭解(2)WP:IPBE权限？--❦‽研究及來源 hanteng✉ 2016年8月23日 (二) 12:03 (UTC)
- 估计是Sun自己没意识到“巨大的麻烦”到底是什么意思，以为是Antigng危言耸听瞎胡他，要么是WP:IPBE对于维基初学者来说也难找了一点。气绝仇怨终须报，忠介清明坞不回。越士三人湔闽耻，建德城外艳阳晖（留言） 2016年8月23日 (二) 14:15 (UTC)
- 阅读理解能力，真的很重要……--Kuailong™ 2016年8月23日 (二) 21:56 (UTC)
- 这个讨论有必要吗？中文维基被封，我们跪地求政府也无济于事。要中文维基搞审查，基金会Jimmy Wales这一关也过不了。如果开放IP代理编辑，那些搞破坏的人，可以利用代理以多个IP实施破坏（比如封了61.X.X.X可以再换101.X.X.X，101.X.X.X封了可以换1.X.X.X……）。总之，我们什么也改变不了。上有政策，下有对策。如何应对，相信其他用户以及相关的介绍页面已经给出了清晰的解释。--№.N（留言） 2016年8月24日 (三) 00:48 (UTC)
== 好的，谢谢各位！Talkative Sun 2016年8月24日 (三) 13:51 (UTC)
XsicoDNS
首选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)
编辑请求
请求已处理
XsicoDNS目前已关闭（详见其官网） --114.253.113.1（留言） 2017年9月16日 (六) 08:31 (UTC)
Opera浏览器也可用于访问维基百科
具体步骤请参见：[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
请求已拒绝 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)
- 已恢复，拒绝请求。-- CreampieGolden State Finals Champion 2018年6月23日 (六) 17:59 (UTC)
- IP没有被封，好像是骨干网丢包了---Raindrops2005（留言） 2019年6月1日 (六) 22:56 (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被墙的时候就是这样做的 --BR 2018年8月3日 (五) 11:53 (UTC)
- 哈哈哈哈哈哈哈我早就想到这个了……“我上不去维基怎么办？”“看看Help:如何访问维基百科啊”……哈哈哈哈容我再笑会儿…… --正在学习友谊就是魔法的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)
- [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)
- 現時訪問有間歇性不能出現。——約克客（留言） 2018年8月24日 (五) 10:49 (UTC)
- 看起来是因为V6地址的原因。--Aoke1989（留言） 2018年8月23日 (四) 14:38 (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)
- 看了下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)
- 问题是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)
- 一个小窍门，先访问英文维基百科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)- curl 的发出数据包的 sni server_name 不应该默认和 Host 相同吗，我觉得这条指令应该不能绕过 sni 阻断吧--Space Timee（留言） 2022年4月20日 (三) 09:40 (UTC)
- 即使在英文维基还没有被墙的情况下--Space Timee（留言） 2022年4月20日 (三) 09:42 (UTC)
- curl 的发出数据包的 sni server_name 不应该默认和 Host 相同吗，我觉得这条指令应该不能绕过 sni 阻断吧--Space Timee（留言） 2022年4月20日 (三) 09:40 (UTC)
- IPBE的申请本来就没什么门槛。——星耀晨曦（留言） 2018年8月25日 (六) 23:21 (UTC)
- 有什么浏览器支持域前置（Domain Fronting）吗？由于英文维基不受影响，用
- 我找到一个关于为什么访问其他未被封锁维基百科后还能短暂访问被封语种维基百科的解释（可以的话去互联网档案馆存个档，知识问答里也有用户做出和这类似的解释）。当然，如果维基媒体基金会所有网站全被封或者对应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)
- 这里我想到几个问题，一是ESNI是否有可行性（也就是能不能够实现），要是胎死腹中一辈子都得用VPN（对我来说VPN最麻烦的地方就在于时不时会掉线……），二是ESNI正式推出后，墙会怎么应对，毕竟这玩意会让Google、Twitter、Facebook等墙的重点照顾对象少去一层封锁手段，少去一层封锁手段可能会令墙推出新的封锁手段：据说墙封锁BBC刚好发生在BBC支持https之后……--№.N（留言） 2018年8月26日 (日) 07:46 (UTC)
- 还有就是坐等TLS1.3推广ESNI给网址加密了。--侧耳倾听 2018年8月26日 (日) 06:36 (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)
- 嗯，现在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)
- 我倒没问题，本身就有内网用的DNS，来源经过安全获得，所以可以不依赖Hosts。至于基于DNS，其实就是用另一条（安全）信道获得一个信任的安全令牌来处理，如果DOT或者DOHS成行的话，DNS的安全性保障了，然后TLS就可以不用完全零信任启动了。至于插件，我认为可能和FF早期可以操作底层网络连接流有关，不过现在最新的不支持旧版插件，即使是次一些版本还是因为这个插件没签名也装不了。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月29日 (三) 02:14 (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)
- 从未见过如此厚颜无耻之基金会[開玩笑的]--Super Wang 2018年8月27日 (一) 07:38 (UTC)
- 基金会：我们又双叒叕遭到了来自中国的IP地址的DDoS攻击。(／‵Д′)／~ ╧╧
- 试过了上面提到的绕过办法，但是我这里行不通--百無一用是書生 (☎) 2018年8月27日 (一) 07:45 (UTC)
- 偶然是可以，不太确定原因：先en，如果先zh过肯定会不行，必须启用h2支持。——路过围观的Sakamotosan | 避免做作，免敬 2018年8月27日 (一) 08:44 (UTC)
- 试过了上面提到的绕过办法，但是我这里行不通--百無一用是書生 (☎) 2018年8月27日 (一) 07:45 (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)
- 服务器目前问题不大，证书的可选域名支持很多，也不禁止不匹配，但Chrome/Firefox扩展的API改不了TLS的SNI头。我试了重定向请求再改内部'Host'请求头，能用，但地址栏地址会变成重定向后的假地址，一些脚本会因此异常（判断或存储网页域名那些），体验不好。--YFdyh000（留言） 2018年8月28日 (二) 03:13 (UTC)
- 似乎域名前置可以对付这个问题。但首先得服务器支持，其次至少要有插件才可以（我理解没错的话）--百無一用是書生 (☎) 2018年8月28日 (二) 02:33 (UTC)
- 我想知道这个是基于什么原理（这个就是搞出escape插件的那个团队写的，没看懂所以来问）。我现在暂时用老版本的firefox加上这个escape插件，能正常访问。--№.N（留言） 2018年8月28日 (二) 12:59 (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)
- 看例子的话，看来审查各国都有，只是目标不同罢了，手法基本就是那几把板斧。——路过围观的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)
- 有人开发了一个 nosni-proxy 应该可以绕过。另外有人提到攻击，据测试即使将sni分散在乱序的两个包中，墙依然能检测到。有兴趣的人可以考虑类似ip分片攻击的策略。2607:FCD0:100:1926:0:0:C28D:6E0D（留言） 2018年9月17日 (一) 17:23 (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的插件谷歌访问助手也可以访问中文维基百科
使用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本地反代无需代理服务器直连维基百科
- 使用OpenSSL自签证书，CN填
.wikipedia.org，得到rsa.key，cert.csr，cert.crt。
详细步骤
- 生成密钥（Key）:
openssl genpkey -outform PEM -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa.key
- 生成证书（Csr）：
openssl req -new -nodes -key rsa.key -config csr.cnf -out cert.csr
- 签署证书：
openssl req -x509 -nodes -in cert.csr -days 3650 -key rsa.key -config signcsr.cnf -extensions req_ext -out cert.crt
- csr.cnf 内容：
[ req ] default_md = sha256 prompt = no req_extensions = req_ext distinguished_name = req_distinguished_name [ req_distinguished_name ] commonName = *.wikipedia.org countryName = US stateOrProvinceName = California localityName = San Francisco organizationName = FucGFW Foundation, Inc. [ req_ext ] keyUsage=critical,digitalSignature,keyAgreement extendedKeyUsage=serverAuth,clientAuth basicConstraints=CA:false subjectAltName = @alt_names [ alt_names ] DNS.0 = *.wikipedia.org DNS.1 = *.m.wikimedia.org DNS.2 = wikipedia.org
- signcsr.cnf 则在
[ req_ext ]多了一段：
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
- 将rsa.key，cert.crt放入Nginx下的conf目录下，打开该目录下的nginx.conf，加入：
nginx.conf内容
server { listen 443 ssl; server_name zh.wikipedia.org; server_name zh-yue.wikipedia.org; server_name wuu.wikipedia.org; server_name ug.wikipedia.org; server_name ja.wikipedia.org; server_name zh.wikinews.org; server_name zh.m.wikipedia.org; server_name ug.m.wikipedia.org; server_name zh.m.wikinews.org; ssl_certificate cert.crt; ssl_certificate_key rsa.key; location / { proxy_pass https://208.80.153.224/; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real_IP $remote_addr; proxy_set_header User-Agent $http_user_agent; proxy_set_header Accept-Encoding ; proxy_buffering off; } }
- 将cert.crt导入为系统可信证书，
- Hosts文件中的关于wikipedia的IP全改成127.0.0.1
- 启动Niginx，即可直连。
- 该法适用于任何被SNI阻断但IP可连接的网站。
--207.148.113.20（留言） 2018年9月23日 (日) 11:18 (UTC)
- 亲测可用，但(※)注意nginx配置中的空引号被自动隐藏了，应将对应行改为
proxy_set_header Accept-Encoding "";。--Br2 2018年10月1日 (一) 08:16 (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的疑问
看到文中写到中科大和清华大学的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疑似公用代理服务器吗？
如题，详见User_talk:103.114.161.158，其中本人提供了确凿的证据（提供该公共代理服务器的来源页面（有详细的ip等信息）），不知道这样是否可行？（主要还是为了防止被他人滥用此ip来进行破坏和编辑战） 咸鱼老李（留言） 2018年12月9日 (日) 11:15 (UTC)
為甚麼Help:如何访问维基百科和m:Help:如何访问维基媒体旗下项目裡提供的網址有問題
為甚麼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/會返回
-- 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)
- 那要去哪裡根基金會反映？順帶一提，可不可以使用{{ping}}回覆一下？-- Sunny00217 --維基餐廳開幕了，歡迎參觀。 2018年12月2日 (日) 10:45 (UTC)
- 嗯，说得难听的，我感觉你是技术不太全懂但又瞎操心。没必要，这是设计需要，这些IP配置的域名相当于一种方便自动管理的管理用域名，也就是说，证书的域名配置是无问题的，而这些IP的域名是方便基金会管理这些这些IP而设置，证书上不配置这些域名并无必要。例如国际大型ISP的路由设备的IP地址也配置了域名，但是实际路由并不需要这些域名，更多是企业内部方便管理的作用（例如结合域名识别IP设备的部署位置、管理控制等）。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 12:32 (UTC)
- 因為現在是Google Chrome擋掉不給過，Internet Explorer也不給過，甚麼都不給過-- Sunny00217 --維基餐廳開幕了，歡迎參觀。 2018年12月2日 (日) 13:01 (UTC)
- 没发现证书有问题，说一下你在研究什么技术？我是直接用代理附带的端口转发能力，直接通过加密代理出去，然后转发到基金会的地址上。证书一切正常，除了需要用内网DNS修正域名到内网的端口转发地址上。——路过围观的Sakamotosan | 避免做作，免敬 2018年12月2日 (日) 13:16 (UTC)
- 代理或許沒這個問題，但台灣又沒有GFW當然是直連的-- 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)
- 刚刚测试，目前电信对以上ip均可ping通--Space Timee（留言） 2022年4月20日 (三) 13:02 (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)
- @橙子木：这次的情况又不一样了，以前是开一下英文维基百科就可以了，这次是开了中文维基百科后连着英文维基都会被重置，需要等一段时间才能继续。--侧耳倾听 2019年3月31日 (日) 02:16 (UTC)
- 咋没人来讨论呢，难不成都是用VPN的翻墙党？--侧耳倾听 2019年3月31日 (日) 03:14 (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)
- TLS 1.3在没实现ESNI之前，和TLS 1.2的处境差不多。——路过围观的Sakamotosan | 避免做作，免敬 2019年4月4日 (四) 02:17 (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)
- 好像现在不止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)
- 似乎从Commons绕过去还行，当然迟早还是得用上本地反代，甚至VPN --120.236.174.170（留言） 2019年4月24日 (三) 15:59 (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到被封锁的域名，不如让未被封锁的域名CNAME到未被封锁的域名。-- FL.YL.BANxS（留言） 2019年5月9日 (四) 12:43 (UTC)
- @Cwek：我觉得优化还是有必要的，所以我想可以让他CNAME到没有DNS污染的域名（比如说
提议删去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本地反代的访问方法）：
- 纠正一下，本地反代并非只有nginx那个方法，如使用Accesser，默认情况下就会校验证书，以保证安全。-- 几何原本 2019年5月2日 (四) 06:35 (UTC)
- 那这样就没关系了。-- FL.YL.BANxS（留言） 2019年5月2日 (四) 06:43 (UTC)
- 应该直观地提供有效的方法。应该把下文的本地反代移上来，其余的需要另外采取措施绕过SNI RST的放下面去。这个帮助页的目的就是为了解决如何访问维基百科，所以理应把有效的方法放在显要位置。--YouTable 2019年5月1日 (三) 20:35 (UTC)
- 怎么不可用？Hosts、DNS、DoT/DoH的作用都是一致的，都用于得到不受污染的DNS结果。然后绕过SNI RST。-- FL.YL.BANxS（留言） 2019年5月1日 (三) 09:59 (UTC)
- 但现在直接改hosts在中国大陆不可用。--YouTable 2019年5月1日 (三) 09:54 (UTC)
- Hosts比其他方法更加稳定，因为DNS和DoT/DoH的服务器容易被封，所以不能删，而且最稳定的方法应该放到前面。 -- FL.YL.BANxS（留言） 2019年5月1日 (三) 09:51 (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（留言） 2019年5月1日 (三) 13:32 (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)
- 現在Help:如何访问维基百科#镜像网站已經沒有紅色了（被
- 对域名进行DNS查询，然后把NXDOMAIN（域名无解析记录）的删除。剩下的用代理访问，然后把打不开或停止服务的网站删除。-- FL.YL.BANxS（留言） 2019年5月4日 (六) 03:25 (UTC)
- @FL.YL.BANxS：如何查证？--YouTable 2019年5月4日 (六) 02:23 (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)
- 其实就是，一种是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)
- 或者将这个做成一个可以外部配置读取的配置文件，判断域名是否需要SNI修正，不需要的话就照常，需要的话就修正。不过还是那句，硬核玩法。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月20日 (一) 01:20 (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)
半突发新闻
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)
- 近期墙动作也是不少，以前用来存档的archive.is只是DNS污染，周末的时候发现也上了SNI了。--求🔨得🔨 2019年12月2日 (一) 01:20 (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)
- 看了下反向DNS，是
维基百科全站已经解封？！
中国移动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的？
印象当中好像很长一段时间是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)
路由调整
- 中国电信至新加坡、荷兰、旧金山三个节点不再经Cloudflare的网络承载（如果需要经Cloudflare网络，必须通过中国电信北美的公共POP出去）。也就是按往常路径，各走各路。
- 新加坡节点会从日本的POP出去，通过NTT承载到新加坡的流量，这样就不用“环太平洋游”了。当然考虑到中国电信经NTT到日本的流量质量嘛……
- 中国电信与zayo的连接仍然要绕欧洲。
承接“请问维基百科是何时被封IP的？”的讨论。——路过围观的Sakamotosan | 避免做作，免敬 2020年4月7日 (二) 06:27 (UTC)
- Clouldflare开始做IP transit了？我还以为维基媒体开始吧自己的服务放在Cloudflare的云端上面了呢。--侧耳倾听 2020年4月16日 (四) 06:15 (UTC)
- 可能是“钱实在是太多了”（前面就提过，基金会的DC被人打，所以订了这款特殊服务。应该是为了让CF来做透明清洗？）——路过围观的Sakamotosan | 避免做作，免敬 2020年4月20日 (一) 02:16 (UTC)
美国旧金山的图片服务器 198.35.26.112 可能被封锁
用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)
图片服务器已被墙
各位维基百科人大家好：
特此报告，图片服务器（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都已失效
GFW可以執行SNI阻斷，只能望Wikipedia提供ESNI功能。 奧田95（留言） 2020年6月8日 (一) 10:24 (UTC)
- 目前ESNI属于草案（即实验性功能），故支持此功能的希望渺茫。您可以通过本地反代或非直接连接的方式（如：镜像网站）继续访问维基百科。 --安忆Talk 2020年6月20日 (六) 05:48 (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)
- @Cwek：可为什么tcping新加坡IP却能通呢？Probing 103.102.166.224:80/tcp - Port is open - time=202.008ms --Liuxinyu970226（留言） 2020年5月30日 (六) 00:45 (UTC)
- upload-lb也被ko了，103.102.166.240ping了半天ping不通。--Liuxinyu970226（留言） 2020年5月23日 (六) 08:37 (UTC)
- 毕竟新加坡节点相对于其他的节点有距离上的优势。--🔨（留言） 2020年5月23日 (六) 04:37 (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)
- @Cwek：你叫我怎么测出“5跳就通”，我这边除了某些超时结果，前12跳全是10.几的内网IP地址。--Liuxinyu970226（留言） 2020年6月6日 (六) 04:49 (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)
- 指的是ulsfo的节点（198.35.26.96）被封锁的事情。--🔨（留言） 2020年6月12日 (五) 06:23 (UTC)
- 哦，明白了。其它的维基媒体项目只是被DNS污染，并没有被SNI照顾。你所说的“ulsfo的锅”指的是什么？162.211.224.40（留言） 2020年6月11日 (四) 12:02 (UTC)
- @162.211.224.40：不不不，只有维基百科和中文维基语录被照顾而已，其他的都是ulsfo的锅。--Liuxinyu970226（留言） 2020年6月11日 (四) 01:16 (UTC)
- ……不想和半吊子讨论这些问题了。简单就是，测一下tcp的traceroute。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月6日 (六) 03:26 (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)
- ESNI一来，保准全部IP都会封掉，当然，也不排除ESNI来之前IP就已全被封的可能性。--🔨（留言） 2020年6月13日 (六) 13:15 (UTC)
- 都封到这个份上了，还是不上IP地址封杀。而且维基媒体所有的项目的IP地址就那么几个。墙果然不是逻辑可以理喻的。162.211.224.40（留言） 2020年6月13日 (六) 13:02 (UTC)
- @Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 “AS”在这儿指的是Autonomous System自治系统吗？162.211.224.40（留言） 2020年6月14日 (日) 13:06 (UTC)
- 如果出于心理安慰的话，可以这么想。虽然好像记得最开始测定时没发现eqiad有这个问题，而且服务器是租赁的，但是对应的地址段都是基金会自有的（也就是在DC的接入线路上宣告路由），并在同一个AS里面，实际上如果对同一个AS做同样的事，一个都逃不掉。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年6月13日 (六) 02:37 (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)
- 我也看不懂你在说什么。你是怎么得出能收到HTTP 504就是TCP没有问题的结论的？你是“用户-维基新加坡节点”直接连接，而我是使用每时每刻都在与维基新加坡节点进行通信的、香港PCCW网络的香港服务器反代维基新加坡节点，连接全程是“用户-香港服务器-维基新加坡节点”，香港难不成也有墙？用户看到的504 Gateway Timeout是由我的服务器发出的，表示的是“香港服务器-维基新加坡节点”这段超时。服务器的错误日志为
- 我看不懂你在说什么。能收到 HTTP 504自然是TCP没有问题。我刚测试的结果，ICMP 和 TCP 80 都没有问题，TCP 443 握手成功，但当客户端发出Client Hello开始TLS握手的时候开始丢包。另外
- (～)補充：是直接访问网页的HTTP 504超时（即TCP），不是Ping IP。 --安忆Talk 2020年6月26日 (五) 00:29 (UTC)
- 也就是说美国阿什本和新加坡这两个数据中心都是租赁Equinix公司的数据中心，而Equinix公司的数据中心的服务器现在正在被墙TCP重点关照，所以维基媒体设在Equinix公司的数据中心也就被TCP躺枪了？162.211.224.40（留言） 2020年6月12日 (五) 21:04 (UTC)
本地反向代理没有自行签发、导入证书的必要
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)
- Pixiv-Nginx用的不是自签证书吗？是吧，它需要先安装根证书（CA），然后Nginx用的就是这个CA签发的域名证书。因为这个CA在系统里是可信的，所以这时自签的域名证书也是可信的。Firefox只是用了它自己内置的根证书列表而已，也是可以导入其他证书的。至于您说的HSTS，它只验证证书的信任链是否完整，而不是区分是不是自签的，所以只要系统或浏览器里有可信CA就可以了。 --安忆Talk 2020年7月19日 (日) 13:48 (UTC)
- 务必提醒一下：Firefox会拒绝自签名证书，在有HSTS的情况下导入了也没用。而Pixiv-Nginx用的证书不是自签名证书。--GZWDer（留言） 2020年7月19日 (日) 13:33 (UTC)
路由信息更新
新加坡节点和阿什本节点text接入点的tcp诡异路由现象消失。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月12日 (三) 01:30 (UTC)
火狐浏览器域前置修改更新
各位维基人大家好：
最近有幸能够在Ubuntu 19.10上修改【最新】的火狐浏览器代码。所以更新一下20