維基百科

說明討論:如何訪問維基百科/存檔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" 頁面。