Help talk:如何访问维基百科

Android（移动）端的直接连接方法

似乎#直接连接方法中的所有方法都只能在电脑上使用？有没有能在Android端使用的类似方法？（注意，我指的不是使用代理服务器的方法）--Wnotieagusdr（讨论 | 贡献） 2024年2月1日 (四) 06:10 (UTC)

见“本地代理工具”，Accesser可以在Termux中运行[1]，然后你要配置浏览器使用http://localhost:7654代理。--Shinohara Chihiro（留言） 2024年2月1日 (四) 07:23 (UTC)

我不太会用，还遇到了问题……先问一下我的操作对不对：一行一行地输入这个链接中的命令。但这样，我在执行python -m pip install -i https://mirrors.bfsu.edu.cn/pypi/web/simple --upgrade pip时遇到提示（红色字）：

ERROR:Installing pip is forbidden, this will break the python-pip package(termux).

这该如何是好……

--Wnotieagusdr（讨论 | 贡献） 2024年2月3日 (六) 07:17 (UTC)

这段错误是因为Termux不允许pip自己更新自己，只允许通过其pkg包管理器更新它。这行命令不是必要的，你可以直接略过。--Shinohara Chihiro（留言） 2024年2月3日 (六) 09:37 (UTC)

抱歉啊，作为非专业人士，我觉得在没有一个系统的教程或者便捷的方法的情况下，我可能是没法完成了（笑）。我把每一步都做了，最后却连网都连不上了，说是要验证什么的（或许是安装证书或者配置代理的问题……所以我觉得我可以暂时放弃了233，感谢您的指导。--Wnotieagusdr（讨论 | 贡献） 2024年2月13日 (二) 12:04 (UTC)

@Wnotieagusdr：你应该不是在浏览器，而是在WLAN设置里添加代理的，才会让系统误以为网络需要认证。如果你的浏览器没有设置代理的选项，可以试试这个[2]，在其“设置”的“隐私和安全”中找到Proxy configuration，然后选择Use a single proxy，填入PROXY localhost:7654，然后Apply就可以了。--Akishima Yuka（留言） 2024年2月13日 (二) 13:21 (UTC)

然后需要让浏览器信任Accesser的证书，先去系统设置的隐私和安全中安装Termux应用目录中的root.crt作为CA证书，然后去Cromite浏览器的Cromite flags list中启用Allow user certificates。--Akishima Yuka（留言） 2024年2月13日 (二) 13:25 (UTC)

@Akishima Yuka：感谢，我照做了，但是我如果访问zh.wikipedia.org，浏览器就提示“您的连接不是私密链接”（NET::ERR_CERT_AUTHIRITY_INVALID），Termux中提示ssl/tls alert certificate unknown (_ssl.c:1006)。我怀疑是证书安装有问题，我是在 系统设置-安全-更多安全设置-加密和凭据 里安装的，在其中的 受信任的凭据-用户 里能看到叫Accesser的证书（我是HarmonyOS的系统），然而可能还是有问题……--Wnotieagusdr（讨论 | 贡献） 2024年2月17日 (六) 13:55 (UTC)

@Wnotieagusdr：

Cromite浏览器的Cromite flags list中启用Allow user certificates。

在“设置”-“隐私和安全”-“Open Cromite flags list”，设置为“Enabled”。--Akishima Yuka（留言） 2024年2月17日 (六) 15:17 (UTC)

@Akishima Yuka：是的，我已经做了……--Wnotieagusdr（讨论 | 贡献） 2024年2月21日 (三) 02:00 (UTC)

🤔...--Shinohara Chihiro（留言） 2024年2月21日 (三) 05:25 (UTC)

斜坡计划的安全补丁

先前讨论：1 2

简易流程图

很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题（政府可能留下门户的访问记录，可以与注册日志一一对应），在下最近想出一个解决办法：门户只发放临时账号，永久账号转发给IPBE授予系统处理。

大致思路是：用户在注册门户注册时，如果希望长期贡献，可以选择注册永久账号。提交申请后，门户提供一个临时账号用于编者即时编辑（可以限制使用时间，如一个月，或者根据ipbe授予的积压情况决定），同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。

如果安全问题能够解决，我觉得应该不会有太大的阻碍，希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)

没看懂。是自动发放一次性账号？怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题，随机延迟不就行了，不过我觉得意义不大，因为访客数量有限、网络特征公开。--YFdyh000（留言） 2024年2月15日 (四) 16:37 (UTC)

如果門戶是維基媒體基金會的網站，不存在什麼可信不可信。用戶貢獻歸屬，新用戶會在意這個？別人只想編輯。滥用這個詞太抽象，不知道你指的是什麼，最好說明一下更具體的情況。--日期20220626（留言） 2024年2月15日 (四) 17:00 (UTC)

1. 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系，使通过代理的注册和编辑更可见和可控（Tag/每笔人机验证/反破坏更敏感/二次审核，等等），将有益全域。
2. 如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。
3. 会的，并且牵扯到傀儡判定、条目主编者等问题。
4. 不太懂这样做对隐藏身份的意义，IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小。
5. 创建临时账号非人工审查，LTA可以用完就扔，未见反破坏机制，人工审封IP不太可靠、会误伤。
6. 如果门户是为保障时间点隐私，就不宜支持即时提交编辑。

--YFdyh000（留言） 2024年2月15日 (四) 19:28 (UTC)

1. 「研发与优化开放代理与反破坏机制的关系」，基金會這方面有什麼動作嗎？沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶，不會特地去為了中維去開發這麼一個門戶。
2. 那你等有人真的用了門戶出事情再說，不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓[3]，說明翻墻上維基百科本身就有一定風險，也沒見基金會出來說要保護或者出面去介入。
3. 傀儡判定，之前討論說允許把本地IP提供給查核員，這個可以再討論一下。不過本身在不用翻墻的地區，傀儡就可以隨意創建賬號登入編輯。非大陸地區的LTA本身就會用完賬號就扔。你看影武者都有多少賬號了。這個門戶主要面對新用戶的，新用戶不會想到条目主编者這一層面。你10年前剛編輯的時候你會考慮這個？

--日期20220626（留言） 2024年2月16日 (五) 05:23 (UTC)

1. 从基金会的开发效率及意愿来说，我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全，如果无所谓，IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目，注册账号编修，或者多个临时账号编写，DYKC主编、傀儡活动怎么算。注册时间隐藏，听上去需要提前注册储备一些临时账号。如果是先用后审，似乎没意义啊。--YFdyh000（留言） 2024年2月17日 (六) 05:11 (UTC)

3. 临时账号的用户名应该有特定规律，视作因为隐私问题而不公开披露sockpuppeteer的分身账号。临时账号的注册时间不隐藏，门户界面告知使用有安全风险。如果编辑不敏感的条目或者头铁的自然承担风险就是。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:34 (UTC)

补充，我的临时账号想法是IPBE申请系统自动/半自动创建所请求账号，限制有效时长和编辑次数，超出有警告与自动封禁/剥夺IPBE，配合过滤器自动封禁，之后人工审核和批准永久IPBE（类似WP:AFC）。这之前讲过。我的想法中IP验证并非必选项，甚至不考虑，但如何避免傀儡反复注册，暂时只想到人机验证；答题可选；网页版工作量证明也许会有帮助。--YFdyh000（留言） 2024年2月17日 (六) 05:22 (UTC)

这样甚至比现行IPBE还严格，要知道目前IPBE授予和自动授予没有太大的区别，如果我没搞错的话，如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)

目前问题是处理时延太久，而我的提议为人机校验（及其他自动检测）后先发后审但限制编辑能力（次数和范围），是否永久批准仍是传统流程。--YFdyh000（留言） 2024年2月17日 (六) 05:48 (UTC)

誰會用這個門戶？當然是新用戶和一些圖謀開傀儡的被封的賬戶。如果這一門戶機制不影響查傀儡的話問題不大。--日期20220626（留言） 2024年2月16日 (五) 05:30 (UTC)

4. 永久账号给IPBEG发，和门户就没关系了，也无法通过门户来精准索敌 5. 同日期君。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:32 (UTC)

防滥用措施的可行方案已经写在用户页上，譬如设置管理员、封禁开放代理、同步封禁列表等手段。不清楚门户可信是什么意思，这个系统应该不会处理敏感信息，可以建议开发者开源。署名问题可以提前在注册页告知，临时账号事实上相当于IP用户，也没人关心IP用户或者IP masking的临时账户怎么署名啊。随机延迟可能有用户名撞名的问题，其实解决这个问题也行() ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:28 (UTC)

门户只是申请表单的话，我之前可能想错。临时账号统一命名、提前注册，永久账号等待审核，可能不需延迟。总感觉以IP为IPBE信任元素，很容易滥用，不过非开放代理似乎能达成相同目的。--YFdyh000（留言） 2024年2月17日 (六) 06:07 (UTC)

@魔琴、YFdyh000、日期20220626：請問考不考慮讓這討論改走RFC機制？Sanmosa _{起視四境　秦兵又至} 2024年2月16日 (五) 06:40 (UTC)

我無所謂。--日期20220626（留言） 2024年2月16日 (五) 06:42 (UTC)

太多想法未确定，为免含糊的支持/反对，目前倾向不要。--YFdyh000（留言） 2024年2月17日 (六) 05:12 (UTC)

IPBE授予員討論尚主要涉及權限方針修訂，這個初步概念應該VPO討論吧。--路西法人 2024年2月17日 (六) 06:19 (UTC)

前幾次討論都是在其他區；此案目前尚未涉及實際方針與指引修訂。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月17日 (六) 07:30 (UTC)

這樣的話，考慮到VPP這裏的長度問題已經比以前改善不少了，那就不一定要搬了。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月17日 (六) 08:50 (UTC)

已移动到VPO ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 09:36 (UTC)

认为应该在易于申请、保护隐私和反破坏中寻求平衡。这应该是一个排序题，而不是选择题。

应该如何给申请人分发临时账户，又该如何收回？我建议使用一个独立的表单，让用户提交要发送的代码和延时时长，以达到编辑目的。

这个提案不同于大部分讨论，是在商议软件需求。我们不能写一个复杂而模糊的需求难为开发人员，所以我们要把所有细节敲定了，再和开发人员提出。考虑到本地实际，这必然需要长久的讨论，因此提案人不必担心重复提出。

( π )题外话如若通过，可否将IPBE授予系统一并开发？--落花有意12138 2024年2月17日 (六) 15:51 (UTC)

临时账号我倾向一次性而不是回收再利用，避免贡献混淆。预先批量申请，通过时发放账号密码。延时注册是可选需求，如果IPBE永久授权依旧很费时、批次授予，可能无所谓。如果只是要验证IP，可以将验证模块站点独立出来，也不需要将申请表单放在上面，直接一个附令牌的网址访问、自动检查风险（建议搭配人机验证）、确认，原网页/邮件系统发放账号密码就可以了，这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”，除了风险检查机制，授予系统是否只是一个表单管理系统。--YFdyh000（留言） 2024年2月17日 (六) 16:08 (UTC)

如果临时账户不收回为什么不直接把临时账户改名？

认为单设验证站点可行。--落花有意12138 2024年2月19日 (一) 11:34 (UTC)

用户更名的复杂度好像较高，比如可能涉及全域账户？最低复杂度就是立即创建+有条件IPBE吧。--YFdyh000（留言） 2024年2月19日 (一) 12:28 (UTC)

其實社群可自行開發，並非必須交由基金會開發（例如本站不少小工具就是由社群開發的），更何況基金會資源及人手有限，也不太可能幫助本站開發這規模的系統。謝謝。--SCP-0000（留言） 2024年2月17日 (六) 16:33 (UTC)

非常同意。但该计划意图以中国大陆用户IP地址为认证手段，且需要经常维护（反LTA），并从IPBE与NDA保密条款的近期讨论风向来看，我觉得较难有符合信任条件的维基人参与运维建设。--YFdyh000（留言） 2024年2月17日 (六) 16:51 (UTC)

“临时账户”和“永久账户”这个概念还是太新颖了。如果用类似IP Masking的机制的话，是不是需要基金会或者其他技术上的配合（IP Masking好像是准备预留一个用户名前缀）？另外始终无法解决庙的问题：放外面，域名地址维护成本（“游击战”对抗）和可用性维护难以维持，甚至可能扩大损害（更多地址被黑洞）；放里面，有信任风险。临时账户这个概念和现在IP用户机制类似，可能增加条目质量沟通成本。或者退而求其次：门户用于地址验证和提交邮箱地址（等联系方式）申请，然后管理员在门户管理后台审阅并代申请后回发（本来就有代创建账户，并通过邮箱回发的机制）；这样的可行性可以观望，虽然仍然有庙的问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:07 (UTC)

1. 不需要，设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述，表单等放在需代理的页面，可以仅将IP与人机验证页面放在小型VPS上（及用容器快速部署）、结果回传主服务器，域名不清楚能否免费或直接用IP+证书，证书用免费的。3. 沟通成本，暂未考虑，其他匿名用户一样的。4. 只有地址验证需要门户，表单、管理等系统都可以独立设置。--YFdyh000（留言） 2024年2月18日 (日) 08:38 (UTC)

所以就是庙的问题：这样的门户注册机制真的要搞成打游击模式？或者简单来说，我非常不看好这样的计划。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:52 (UTC)

另外，“临时账号”这个机制我认为就是画蛇添足，可以考虑给这类申请的账户“永久化”并分发一个短期的LIPE（参照现行的不活跃机制的话，6个月为建议上限），同时可以增发一份提醒，可以通过“锻炼”编辑的方式，积累有助于判断申请用户编辑长期性的好感，临期时允许申请延长LIPE，可以进一步提升上限。这样可以减少引入更多不必要的技术性改动。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

在WMF站下搞什么东西都逃不过庙的问题，也许确实该考虑与第三方网站合作？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:02 (UTC)

WMF大概不會喜歡社群自己搞工具還將個資放第三方網站，最終出了什麼事也難以追責。--路西法人 2024年2月28日 (三) 14:54 (UTC)

@魔琴：，“LIPE”就是IPBE，“L”就是Local（本地）。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月19日 (二) 09:17 (UTC)

悉。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月19日 (二) 09:22 (UTC)

en的en:Wikipedia:Unblock_Ticket_Request_System其实可以一定程度上充当这类账户申请和封锁接触申请的门户，甚至不同部署方式主要业务功能也可以面向不同（放里面，只保留账户申请登记和地址信息查验，不添加项目用户登录绑定来实现项目权限功能联动，就是一个简易的账户申请系统；放外面，加上项目用户登录实现权限功能联动，可以不保留账户申请登记，就是UTRS+），当然问题是，谁写或者引进改造这套系统。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:36 (UTC)

印象里英文那套系统未设计本地化支持，改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000（留言） 2024年2月18日 (日) 08:40 (UTC)

UTRS可以参考想法，而不只是实现，实际上现在申请门户系统就是上面描述的类似设计思路。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

引進做處理用途似乎可以？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 17:52 (UTC)

還有OAuth還是有必要的。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 18:16 (UTC)

這裡還是副知一下@Bluedeck。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月19日 (一) 08:43 (UTC)

谢谢ping，确实是我很感兴趣的话题。Bluedeck 2024年3月3日 (日) 01:44 (UTC)

XD —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年3月4日 (一) 11:37 (UTC)

參考英維做法，VPO也是可以掛RFC的，既然也是要增加曝光度，不防也掛上RFC來嘗試讓更多人看到這個討論？不過RFC仍在早期運作，效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)

，要不我把几部分拆分讨论 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月9日 (六) 13:59 (UTC)

拆吧--路西法人 2024年3月11日 (一) 08:33 (UTC)

分段1

稍微整理一下上方的发言，目前的讨论千头万绪混乱不堪。（著作权声明：下面部分内容原文来自上方讨论，CC BY-SA 4.0）括号【】内为可能的解决方案或者我本人的评论：

1. 安全：
   • 1.1 如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。【门户界面告知使用有安全风险，不接受的直接走IPBEG流程。信任问题没什么头绪】
   • 1.2 IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小，意义不大【如果社群同意意义不大的话安全问题似乎没有了？】
   • 1.3 如果门户是为保障时间点隐私，就不宜支持即时提交编辑【可能在本计划的scope之外】
   • 1.4 维基人做这个有信任问题
2. 账户问题，比如傀儡和署名：
   • 2.1 牵扯到傀儡判定、条目主编者等问题【一次性临时账户应该可以解决：临时账号的用户名应该有特定规律，视作因为隐私问题而不公开披露sockpuppeteer的分身账号。】
   • 2.2 创建临时账号非人工审查，LTA可以用完就扔。反破坏机制中，人工审封IP不太可靠、会误伤。【并非这个系统的特色问题，普通反破坏也适用】
   • 2.3 如果用类似IP Masking的机制的话，是不是需要基金会或者其他技术上的配合（IP Masking好像是准备预留一个用户名前缀）。【设置统一的用户名前缀及过滤器避免外人注册即可。-->全域账户怎么办？】
   • 2.4 可能增加条目质量沟通成本。【和普通匿名编辑的问题相同，不考虑】
3. 效率和运维问题：
   • 3.1 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系，使通过代理的注册和编辑更可见和可控（Tag/每笔人机验证/反破坏更敏感/二次审核，等等），将有益全域
   • 3.2 社群可自行开发，并非必须交由基金会开发。另外考虑到基金会资源、人手、开发效率和意愿，不太可能开发
   • 3.3 该计划意图以中国大陆用户IP地址为认证手段，且需要经常维护（反LTA），并从IPBE与NDA保密条款的近期讨论风向来看，我觉得较难有符合信任条件的维基人参与运维建设。【可能需要签NDA的来维护，至少接触到IP的方面需要。此外还需要监管员以方便CU】
   • 3.4 无法解决庙的问题：放外面，域名地址维护成本（“游击战”对抗）和可用性维护难以维持，甚至可能扩大损害（更多地址被黑洞）；放里面，有信任风险。

其他建议：

• 先审后发：自动/半自动创建所请求账号，限制有效时长和编辑次数，超出有警告与自动封禁/剥夺IPBE，配合过滤器自动封禁，之后人工审核和批准永久IPBE。【可能比现行政策严格？】
• 门户只用于申请：门户用于地址验证和提交邮箱地址（等联系方式）申请，然后管理员在门户管理后台审阅并代申请后回发。【似乎和IPBEG那边的VRT、CP差不多？】
• 延时编辑：独立的表单，让用户提交要发送的代码和延时时长，以达到编辑目的。【与本计划无关。另外编辑冲突怎么办？】
• 不授权IPBE：门户只发帐号密码。【不是，只发帐号密码有什么用？？】
• 不需要用临时账户的模式：分发一个短期的本地IPBE（譬如有效期6个月为建议上限），临期延长。【临时账户方案是针对先前的安全问题（运营商记录对比注册日志锁定现实人物）提出的，不过这个方案应该可以解决部分维基人对于自动授权的不信任问题？个人倒是觉得没有什么好不信任的，毕竟现在IPBE的发放现状摆在那里】

大致这样。也许可以一部分一部分地讨论、研究，并且解决？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月19日 (二) 09:37 (UTC)

Wikipedia:互助客栈/其他#Unblock-zh.org--Dnaimfz（留言） 2024年5月15日 (三) 08:08 (UTC)

深度包检测无法复现

我尝试复现帮助正文中的深度包检测: "对于未加密的HTTP连接，该技术可以检测详细的传输内容，如果触发敏感词则立即发起TCP重置攻击"。根据论文 "Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China" [4]，我用 postman 先后发送请求 http://github.com/search?q=我的奋斗 (Get 请求，违禁词: 我的奋斗)，http://github.com/search?q=法輪功 (Get 请求，违禁词: 法輪功)，http://github.com/search?q=习近平 (Post 请求，可能的违禁词: 习近平)，http://github.com/search?q=色情 (浏览器访问，违禁词: 色情)。结果均接收到了完整且正确的响应 (200 OK)，并未出现帮助正文、论文等提到的 rst。测试环境: 大陆内地，未使用代理等特殊技巧，未做额外加密，github.com 处于解禁状态，可不需要任何技巧直连。 ---- Space Timee（留言） 2024年5月15日 (三) 13:41 (UTC)

@Space Timee：对HTTP Path检测是非常老的策略，现在我猜测已经被弃用，敏感词列表也不再更新。甚至对HTTP协议本身的检测也已经停止了，比如最近某年被封锁的i.pximg.net就是只检测HTTPS SNI而不是HTTP Host头。这里有一份出现在HTTP Path中就会触发重置的关键字列表：[5]。目前我看到的在你说的情况会触发重置的只有两个词：“动态网”和“自由亚洲电台”。请求http://github.com/search?q=自由亚洲电台试试吧。--Akishima Yuka（留言） 2024年5月15日 (三) 15:44 (UTC)

是的，我用 postman 成功触发了“动态网”和“自由亚洲电台”的深度包检测，并收到了 rst，谢谢你的解答

GFW 的变化速度真的很快，三年前的论文放到现在已经有很多内容过时了 ---- Space Timee（留言） 2024年5月16日 (四) 05:15 (UTC)

成功触发了“动态网”和“自由亚洲电台”的深度包检测

其实你这个说法有些问题：DPI不是能不能被触发，而是一直都在、对每个连接都有，只是没匹配到预设定词就不会注入重置，但是即使不注入也可能会记录访问日志，像美国的棱镜就是只记录不注入东西。--Akishima Yuka（留言） 2024年5月16日 (四) 06:28 (UTC)

据说现在的DPI改到光猫上了……哈人--Dnaimfz（留言） 2024年5月16日 (四) 15:28 (UTC)

这个帮助页感觉没有用

因为没有被封锁的用户可以访问维基百科，所以不需要这个页面，被封锁的用户无法看到这个页面。--Jonathan（留言） 2024年6月15日 (六) 19:36 (UTC)

给挂了镜像又想做编辑看的，或者某些海外注册又回到墙内的人看的。而且关于服务器IP的信息这里也能看，方便做配置。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月16日 (日) 03:26 (UTC)

明白了。--Jonathan（留言） 2024年6月16日 (日) 14:30 (UTC)

H:VISIT提到的Xray分片直连方法有没有可能在手机上使用？

如题，已知v2rayNG使用的是Xray-core，支持数据包分片，理论上可以通过分片法直连维基百科（甚至包括V2EX、Google等其他被SNI的网站），但是VISIT提供的配置文件在v2rayNG上似乎是无效的（至少VPN模式下启动之后直接上不了网了），所以有没有可能通过修改一部分配置文件的内容在手机上直接运行它？--忒有钱 🌊塩水あります🐳（留言） 2024年6月24日 (一) 16:38 (UTC)

Unblock-zh.org

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)

超 英 趕 美 —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年4月29日 (一) 08:09 (UTC)

我最期待的畫面出現了。--AT 2024年4月29日 (一) 09:14 (UTC)

好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。 赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)

非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)

另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)

非常好软件。

不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）

另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)

一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)

使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)

如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。

mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)

在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)

的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)

咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang^★ 2024年5月8日 (三) 01:14 (UTC)

真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)

用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)

赞 赞 赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)

@Bluedeck：話說可給管理員布告板抄送一份通知連結至此？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月1日 (六) 08:43 (UTC)

@Bluedeck：想好奇請問是否有考慮過部屬在wikitech:Help:Cloud VPS？如果有，為什麼不選擇部屬在該處？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)

管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)

以我個人看法，部屬在CloudVPS的隱私疑慮絕對會比一個外部網站好很多，當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的，如果開銷太小的話我自己是會考慮換過去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)

可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。

另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang^★ 2024年5月14日 (二) 01:47 (UTC)

• 谢谢提议！简短回应：

• 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
• 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
• 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
• link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
• login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
• statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
• Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
• 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。

Bluedeck 2024年5月14日 (二) 04:12 (UTC)

update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)

另外还有两个别的需要讨论的问题：

1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)

感謝貢獻，整體非常完善。如有需要可以協助維護。--Borschts^{™ 歡迎外帶一碗羅宋湯} 2024年5月14日 (二) 13:32 (UTC)

存檔應保留，只是可以限制普通使用者存取。另外，也應考慮先行在站內撰寫說明頁面，或補充現有方針與指引不足，以便利用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年5月14日 (二) 15:05 (UTC)

注意到兩點可以改善：

• 無法創建帳號者不應提供「我不想提供郵箱」的選項，創建帳號時需填寫對方電郵地址才能安全發送臨時密碼。如果不想提供郵箱則難以協助創建帳號。
• 需要添加提示文字，若不提供IP地址則申請有可能不獲受理（始終審批IPBE時需要驗證用戶是否使用proxy）。

--路西法人 2024年5月15日 (三) 07:52 (UTC)

我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登入。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)

我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的，尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的；即使我信任你會盡力保障網絡安全，但顯然不安全的操作應儘可能完全避免。郵件、代理IP地址等都尚算不太危險的資訊，密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)

我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账户，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)

一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月21日 (二) 03:01 (UTC)

另外我在想讓其選擇點選提交IP的選項是否也應該把UA也提供給審核用戶檢閱（方便反破壞比對）。--路西法人 2024年5月23日 (四) 07:54 (UTC)

统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)

2) 啊那就是提前提示創建工單時未提供電子郵件的須放空？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月27日 (一) 06:29 (UTC)

没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)

好的 赞 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月29日 (三) 07:32 (UTC)

---

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)

@Bluedeck：請問IPBEG們可以如何存取工單？--路西法人 2024年7月10日 (三) 03:25 (UTC)

@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)

@Bluedeck：能更新進度嗎？--路西法人 2024年7月22日 (一) 02:49 (UTC)

现在IPBE已经能取得权限使用了，但是目前用户界面和IPBE权限能做的事情不吻合，比如IPBE无权删除工单，但是会显示删除按钮，我正在改这些小问题。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

@Bluedeck：預計試行多久？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月20日 (六) 17:44 (UTC)

不知道，但是目前肯定不是一个完善的状态。比如我就发现了好多好多想要改进的地方，写在Roadmap中。Bluedeck 2024年7月29日 (一) 07:08 (UTC)

IPBEG的权限基本设置完成，测试可用，在此通知IPBEG组成员@user:AINH，@user:ASid，@user:Borschts，@user:LuciferianThomas，@user:SCP-2000，@user:だ＊ぜ。Bluedeck 2024年8月1日 (四) 01:43 (UTC)

感謝。希望未來能添加罐頭回覆（請求提供更多資訊如封鎖訊息、已授權〔時長〕）等。--路西法人 2024年8月1日 (四) 02:21 (UTC)

是的，我自己在处理中，也发现了罐头回复的重要性。我将会加入这个功能。Bluedeck 2024年8月2日 (五) 20:35 (UTC)

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体使用者，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)

新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)

「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[6]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)

@Bluedeck：怎麼查閱或更改翻譯？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月1日 (一) 19:44 (UTC)

通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)

理論上可以開twn（translatewiki.net） project啦，不過要擔心被亂改的問題。--SunAfterRain 2024年7月22日 (一) 07:02 (UTC)

工单的永久删除

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)

应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
   1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
   2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
3. 不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)

設立IPBEG的本意就是許可IPBEG處理該類申請郵件，理論上可以說已有社群共識支持選項2，但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為，一般而言封鎖申訴本應都是在公開場合發起，申訴內容多數都應該可被所有用戶檢視，實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言，IPBEG本有簽署NDA，就算看了也不應該會造成什麼問題（雖然能避免最好）。如果是最後採用最簡化的選項1，那我覺得您可以最低限度在處理人員的界面中加入標籤工單的功能，讓IPBEG能明確標記跟他們職務無關的申請，從IPBE隊列隱藏，僅能由添加標記的IPBEG（直至工單標籤被管理員確認）及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)

如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)

不是「不能看到」，而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列，令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)

分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)

不是不行，但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單，一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)

还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)

我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)

似乎是祇有涉及IP等隱私資訊時，纔要求管理員簽署相關協議。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月23日 (日) 02:13 (UTC)

@Bluedeck：只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年6月6日 (四) 00:11 (UTC)

提供的IP问题

现在有个问题

• 如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
• 是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)
  • 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)

    我有一个方案

    • 申请者不提供IP：不提交IP
    • 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
      • 是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
      • 否：自动带入IP地址

    --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)

    补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)

    检测IP是否中国大陆或其他受限地区 这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)

    • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)

(－)反对，考虑到Unblock-zh未来极有可能受到GFW封锁。--mije meli carrot_233 -- 讨论 2024年7月25日 (四) 11:33 (UTC)

网信办说的？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月25日 (四) 15:07 (UTC)

这种网站大概率被墙。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:42 (UTC)

這反對理由太怪了，你維本來就被GFW刀了，有差嗎？--SunAfterRain 2024年7月27日 (六) 04:23 (UTC)

问题在于，如果Unblock-zh被GFW封锁，则中国大陆无法直连Unblock-zh，故无法获取真实IP。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:41 (UTC)

我们本来就不是为了获取用户的国内IP，因为目前邮件列表也只是看到你的查封ID和IP地址就对你进行授权，这被查封的IP地址往往都是VPN、代理地址。如果被墙后，还能解决代理不是全局的问题。因为没有被墙，有的代理会把没被墙的网站不走代理，导致我们接收到用户的没有被查封的IP地址，反而不是我们想要的。Bluedeck 2024年7月30日 (二) 16:50 (UTC)

罐头回复

经由路西法人的建议，增加了『罐头回复』功能。将常用的语句加入罐头回复列表，就能快速的一键回复工单。详见WP:Unblock-zh.org#罐头回复功能 Bluedeck 2024年8月12日 (一) 21:51 (UTC)

`ChooseNewName`标签

这是一个比较新的功能，当请求用户选择新的用户名时，加入`ChooseNewName`标签，同时摘掉`回复关闭`标签的情况下，工单用户界面会多出一个小工具，便于用户确认自己所选择的用户名是否可以注册。Bluedeck 2024年8月20日 (二) 08:16 (UTC)

長期維護展望

本站不乏一工具或機制，於原維護者隱遁後即生極大之運行困難。若來日Bluedeck不再活躍，此工具是否有辦法由他人接手維護？有必要提前考慮。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月29日 (四) 10:14 (UTC)

教学视频

@Bluedeck：由于YouTube经常删除用户上传的风格，和其最近清理不活跃账户的政策，请考虑将视频上传至维基共享资源。--Akishima Yuka（留言） 2024年11月23日 (六) 06:45 (UTC)

“Chromium内核浏览器启动参数”方法在Edge上用不了

有可能是目标路径上有双引号和空格的原因，导致这一方法失效。Chrome上是可以用的。--Thyj (คุย) 2024年7月26日 (五) 11:30 (UTC)

路径如下："C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --host-rules="MAP *.wikipedia.org wikidata.org, MAP commons.wikimedia.org wikidata.org" --host-resolver-rules="MAP upload.wikimedia.org 208.80.154.240, MAP wikidata.org 185.15.59.224"--Thyj (คุย) 2024年7月26日 (五) 11:37 (UTC)

Edge 好像最近的版本會在後臺保持運行，即使你把瀏覽器窗口關掉。你可以試試看去 Task Manager 裏面確保 Edge 的進程已經被殺掉了。

另外這一方法穩定實現需要更改 hosts 文件，改完以後 --host-resolver-rules 那段就可以去掉了--Moonshimmer93（留言） 2024年8月6日 (二) 18:42 (UTC)

edge://settings/system，关掉启动增强和在 Microsoft Edge 关闭后继续运行后台扩展和应用，另外要注意你的Windows系统有没有侧边栏的Copilot，如果有，需要手动在任务管理器里杀进程--Bovemdep（留言） 2024年9月1日 (日) 05:22 (UTC)

实际上只需要在右上角三个点的菜单中点关闭 ms edge 而不是直接关闭窗口就可以了完全把 edge 关闭了--Space Timee（留言） 2024年10月14日 (一) 14:33 (UTC)

因为现在的Windows 11已经把侧边栏的Windows Copilot换成了Copilot PWA--Bovemdep（留言） 2024年10月19日 (六) 10:30 (UTC)

《网络数据安全管理条例（草案）》和Unblock-zh.org

先前讨论

Help_talk:如何访问维基百科/存档3#互联网信息服务管理办法（修订草案征求意见稿）、Help_talk:如何访问维基百科/存档3#网络数据安全管理条例（征求意见稿）

新闻

国务院总理李强8月30日主持召开国务院常务会议，研究推动保险业高质量发展的若干意见，部署落实大食物观相关工作，审议通过《加快完善海河流域防洪体系实施方案》和《网络数据安全管理条例（草案）》，讨论《中华人民共和国海商法（修订草案）》。

《网络数据安全管理条例》之前的征求意见稿里包含“数据跨境安全网关”相关内容。

第四十一条 国家建立数据跨境安全网关，对来源于中华人民共和国境外、法律和行政法规禁止发布或者传输的信息予以阻断传播。

任何个人和组织不得提供用于穿透、绕过数据跨境安全网关的程序、工具、线路等，不得为穿透、绕过数据跨境安全网关提供互联网接入、服务器托管、技术支持、传播推广、支付结算、应用下载等服务。

境内用户访问境内网络的，其流量不得被路由至境外。

之前的讨论节选

之前的讨论节选

赋予IPBE取权限不知道算不算“提供技术支持或者其他帮助”？--百無一用是書生 (☎) 2021年1月11日 (一) 01:32 (UTC) 征求意见稿不一定过；授予IPBE权限应该不算“提供技术支持或者其他帮助”，毕竟对方连不到站点的话给账号以权限也没有用。--安忆Talk 2021年1月11日 (一) 02:21 (UTC) 中文维基应对中国大陆用户做一个法律风险提示和免责声明了。桐生君★[讨论] 2021年11月14日 (日) 17:30 (UTC) 似乎主要是针对机场，而不是个人？注意关键词“提供”。在这种情况下，个人有技术能力搭建VPN自用且不分享似乎不受限制？--菲菇＠维基食用菌协会 2021年11月14日 (日) 17:54 (UTC) 特别要强调本站不由管理员运营，以免因“境外反动网站和有害信息”拿管理员开刀。桐生君★[讨论] 2021年11月16日 (二) 16:36 (UTC) 镜像站建议都停掉，因为完全符合这个条款，自己翻数据跨境安全网关可能还不符合，但镜像站是肯定的。桐生君★[讨论] 2021年11月16日 (二) 16:38 (UTC) 出于实际考虑，其实本站镜像站维护者很多是在墙内，或具有墙内身份，或需要进入墙内。桐生君★[讨论] 2021年11月17日 (三) 17:37 (UTC) 现在的中国已经陷在全球化之中，一大堆科研（非国家直接管理的）、外贸等需要连接国际互联网的，搞闭关锁国这种玩法已经行不通了，最多恶心下普通的蠢货，而且技术水平的提升也意味着用的人的水平也得跟得上，至少有能力看明白这个糟糕的世界。当然另一个问题是，工具的傻瓜化反而拉低了下限而已。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月18日 (四) 07:13 (UTC) “无论你身处何处，你的镜像站必须维持小众，否则就无法起到其应有的作用。”--这句话说的很对，就算你身处墙外，你的镜像站到达一定的规模依旧有被墙掉的风险。不过在可预见的将来，还是应该大力鼓励我们这些身处墙外的人来多多镜像维基百科。--不爱思考得猪（留言） 2021年11月18日 (四) 06:46 (UTC) 看到这里感觉整个网信办新规的相关的话题变得有些偏了，有必要在这里重归正题。一般这样的征求意见稿变成正式实施的规定要花上至少几十天到数个月。虽然在我看来，不管有没有这样的规则，官方对于翻墙工具的打压力度只会越来越大，Shadowsocks最初的作者受到官方威胁已经是好几年前的事情，GitHub今年年初开始遇上间歇性干扰问题的时候，互联网信息服务管理办法修订还没见到正式确认下来，足以看出他们对于技术手段的传播问题之重视。不过中国毕竟还是需要依赖国际互联网进行科研、外贸、外宣等活动的，这规则似乎并不完美，因为规则当中似乎没有提到任何关于合资格个人或组织（例如跨国企业、外贸电子商务从事者、外宣官媒等）以合理目的获取合法途径访问被封锁网站相关的内容（不过近期有消息提到上海面向企业推出专用的国际互联网通道，广东和澳门在横琴岛建的合作区可以免翻墙，而北京似乎也开始允许向外资推出VPN服务），我等普通维基百科用户对于此条规则提意见，网信办当然不会采纳，不过那些跨国企业、外贸电子商务从事者、外宣官媒等等可就不一定了。鉴于目前仍在意见征集期内，现在我们还是静观其变吧。--🔨（留言） 2021年11月21日 (日) 09:09 (UTC) 说个和维基相关的，如果该条例最终通过，要不要禁止大陆管理员授予用户IPBE权限（某种意义上也算是为翻墙提供技术支持）？--忒有钱🌊塩水あります🐳（留言） 2021年11月30日 (二) 16:34 (UTC) IPBE是用来豁免维基百科为代理IP设置的编辑限制的，如果连WP都访问不了，给你IPBE也没用，这个其他用户先前就回答过了，而且自从基金会行动后，管理员人手现在已经比较吃紧了，当然居住在中国大陆的管理员本身在安全上就要有所顾虑，不管你是否有曾授予他人IPBE权限。一定要限制IPBE权限授予的话，最好视乎此条例具体执行情况再做进一步决定。--🔨（留言） 2021年12月11日 (六) 16:15 (UTC)

新问题

Wikipedia:Unblock-zh.org是不是危了？--Bovemdep（留言） 2024年8月31日 (六) 13:07 (UTC)

审议通过的版本尚未发布？网站的封禁机制不属于“数据跨境安全网关”，因此与此无关。--YFdyh000（留言） 2024年8月31日 (六) 13:34 (UTC)

有沒有可能整個維基百科都不屬於可以存取的內容⋯⋯ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月31日 (六) 20:38 (UTC)

同 Ydyh000，授予 IPBE 僅為便利編輯，而非提供繞過「數據跨境安全網關」。如果授予者或管理員對其安全存有疑慮，離任及停止活躍不失是一個好方法來減低風險。--SCP-0000（留言） 2024年9月1日 (日) 04:54 (UTC)

参考資料

SpaceTimee/Sheas-Cealer

这个应该也属于「SNI伪造」？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月11日 (五) 11:47 (UTC)

本项目仅供学习参考，无意绕过任何审查设备的审查

看到这句话，我感到他在不久之后就会删库了。--Akishima Yuka（留言） 2024年10月11日 (五) 11:57 (UTC)

我都火到我维基老家来了？--Space Timee（留言） 2024年10月14日 (一) 14:29 (UTC)

Sheas Cealer 是我的项目，有问题可以直接问我，阅读别人对项目的评价时还请多加独立思考--Space Timee（留言） 2024年10月14日 (一) 14:37 (UTC)

Sheas Cealer 本身只是一个 sni 伪造工具而已，是不具备让大陆用户访问维基百科的功能的，在添加特定配置文件后可以实现这个功能，如果要把项目的开源地址写进帮助里的话，最好能体现这一点--Space Timee（留言） 2024年10月14日 (一) 15:04 (UTC)

@Space_Timee：感谢贡献。您看看要不要写进去，或者该怎么写吧，这是您的自由。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 09:10 (UTC)

《网络数据安全管理条例》公布

先前讨论

• Help_talk:如何访问维基百科/存档3#互联网信息服务管理办法（修订草案征求意见稿）
• Help_talk:如何访问维基百科/存档3#网络数据安全管理条例（征求意见稿）
• Help_talk:如何访问维基百科#《网络数据安全管理条例（草案）》和Unblock-zh.org

新闻

新华社北京9月30日电 国务院总理李强日前签署国务院令，公布《网络数据安全管理条例》（以下简称《条例》），自2025年1月1日起施行。

条例正文未见“数据跨境安全网关“相关内容。

脚注

签名

Bovemdep（留言） 2024年9月30日 (一) 11:27 (UTC)

删掉原先的第四十一条我是没想到……不过原第四十一条在de facto层面上来说有在执行这一点还是不变的。--💊✖️2️⃣3️⃣（留言） 2024年9月30日 (一) 13:53 (UTC)

几乎整个条例都回炉重造了……另外现在执行的是《国务院关于修改和废止部分行政法规的决定 (2024年)》，删去《中华人民共和国计算机信息网络国际联网管理暂行规定》第六条第一款中的“邮电部”--Bovemdep（留言） 2024年9月30日 (一) 15:43 (UTC)

第三十九条　国家采取措施，防范、处置网络数据跨境安全风险和威胁。任何个人、组织不得提供专门用于破坏、避开技术措施的程序、工具等；明知他人从事破坏、避开技术措施等活动的，不得为其提供技术支持或者帮助。

耐人寻味。--Bovemdep（留言） 2024年10月2日 (三) 14:20 (UTC)

无对应罚则。--Bovemdep（留言） 2024年10月2日 (三) 14:24 (UTC)

这条并没有明确指「翻墙」或者类似活动。如果是的话，这似乎将本地反代、域前置等规避措施（甚至hosts？）也纳入违法范畴了。（本来仅有VPN、代理在利用「违规信道」条款来处罚，理论上这样的处理也是不合法的。如果说全部统一成「破坏、避开技术措施」……有点难评。不过不清楚为什么要用「专门」一词，众所周知VPN、代理最初、最基本的功能就是保护隐私，难道我上维基百科就不能保护隐私了？）无罚则也有意思，但不排除后来加上不是吗 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月2日 (三) 15:09 (UTC)

我也注意到这一条可以被解读为与网络审查相关，不过当时出于谨慎没说出来。还是那句话，有没有明文规定并不重要。--💊✖️2️⃣3️⃣（留言） 2024年10月3日 (四) 02:51 (UTC)

Re@Liu116：在某些情况下很重要，比如要不要在首页公告栏给大陆用户加个警告和免责声明--Bovemdep（留言） 2024年10月3日 (四) 11:07 (UTC)

不需要，有Wikipedia:編輯維基百科危險嗎这个页面来提示用户，并且在更多页面里面合理添加指向该论述的内链足够。即便没有明确的条文规定，执法人员还是可以以各种原因给你强加违法依据进行处罚。--💊✖️2️⃣3️⃣（留言） 2024年10月3日 (四) 11:30 (UTC)

请参考前面的已有讨论

• Help_talk:如何访问维基百科/存档3#互联网信息服务管理办法（修订草案征求意见稿）
• Help_talk:如何访问维基百科/存档3#网络数据安全管理条例（征求意见稿）
• Help_talk:如何访问维基百科#《网络数据安全管理条例（草案）》和Unblock-zh.org

--Bovemdep（留言） 2024年10月3日 (四) 11:50 (UTC)

註：此留言已被原作者（User:Liu116）移除。2024年10月4日 (五) 11:13 (UTC)

Re@Liu116：：我知道呀，所以这个讨论我发的消息区而不是别的什么区--Bovemdep（留言） 2024年10月4日 (五) 06:30 (UTC)

Re@魔琴：境外的“反动有害信息”应该不算“网络数据跨境安全风险和威胁“吧，这个”安全风险和威胁”应该只包括“网络数据跨境“过程中的--Bovemdep（留言） 2024年10月3日 (四) 11:18 (UTC)

我觉得是“网络数据跨境（导致的）安全风险和威胁”而不是“网络数据跨境（过程中的）安全风险和威胁”，行政执法单位大概率不会理解此中不同，具体执法中也没有见到“计算机信息网络直接进行国际联网，必须使用邮电部国家公用电信网提供的国际出入口信道。 任何单位和个人不得自行建立或者使用其他信道进行国际联网。”会按照专业含义进行解读，翻墙还是要被抓。----Cat on Mars 2024年10月3日 (四) 15:02 (UTC)

你法我笑 是这样的 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月3日 (四) 15:11 (UTC)

Re@CatOnMars、@魔琴：我们一直在谈“名义上、理论上”的东西，事实上怎么样我们说了也没用。--Bovemdep（留言） 2024年10月4日 (五) 02:37 (UTC)

还有

第八条　任何个人、组织不得利用网络数据从事非法活动，不得从事窃取或者以其他非法方式获取网络数据、非法出售或者非法向他人提供网络数据等非法网络数据处理活动。

任何个人、组织不得提供专门用于从事前款非法活动的程序、工具；明知他人从事前款非法活动的，不得为其提供互联网接入、服务器托管、网络存储、通讯传输等技术支持，或者提供广告推广、支付结算等帮助。

不知道身在中国大陆的管理员为中国大陆编辑者提供IPBE算不算其中的“明知他人从事前款非法活动的，不得为其提供互联网接入、服务器托管、网络存储、通讯传输等技术支持，或者提供广告推广、支付结算等帮助。”--忒有钱 🌊塩水あります🐳（留言） 2024年10月11日 (五) 16:45 (UTC)

之前的讨论节选

赋予IPBE取权限不知道算不算“提供技术支持或者其他帮助”？--百無一用是書生 (☎) 2021年1月11日 (一) 01:32 (UTC) 征求意见稿不一定过；授予IPBE权限应该不算“提供技术支持或者其他帮助”，毕竟对方连不到站点的话给账号以权限也没有用。--安忆Talk 2021年1月11日 (一) 02:21 (UTC) 中文维基应对中国大陆用户做一个法律风险提示和免责声明了。桐生君★[讨论] 2021年11月14日 (日) 17:30 (UTC) 似乎主要是针对机场，而不是个人？注意关键词“提供”。在这种情况下，个人有技术能力搭建VPN自用且不分享似乎不受限制？--菲菇＠维基食用菌协会 2021年11月14日 (日) 17:54 (UTC) 特别要强调本站不由管理员运营，以免因“境外反动网站和有害信息”拿管理员开刀。桐生君★[讨论] 2021年11月16日 (二) 16:36 (UTC) 镜像站建议都停掉，因为完全符合这个条款，自己翻数据跨境安全网关可能还不符合，但镜像站是肯定的。桐生君★[讨论] 2021年11月16日 (二) 16:38 (UTC) 出于实际考虑，其实本站镜像站维护者很多是在墙内，或具有墙内身份，或需要进入墙内。桐生君★[讨论] 2021年11月17日 (三) 17:37 (UTC) 现在的中国已经陷在全球化之中，一大堆科研（非国家直接管理的）、外贸等需要连接国际互联网的，搞闭关锁国这种玩法已经行不通了，最多恶心下普通的蠢货，而且技术水平的提升也意味着用的人的水平也得跟得上，至少有能力看明白这个糟糕的世界。当然另一个问题是，工具的傻瓜化反而拉低了下限而已。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月18日 (四) 07:13 (UTC) “无论你身处何处，你的镜像站必须维持小众，否则就无法起到其应有的作用。”--这句话说的很对，就算你身处墙外，你的镜像站到达一定的规模依旧有被墙掉的风险。不过在可预见的将来，还是应该大力鼓励我们这些身处墙外的人来多多镜像维基百科。--不爱思考得猪（留言） 2021年11月18日 (四) 06:46 (UTC) 看到这里感觉整个网信办新规的相关的话题变得有些偏了，有必要在这里重归正题。一般这样的征求意见稿变成正式实施的规定要花上至少几十天到数个月。虽然在我看来，不管有没有这样的规则，官方对于翻墙工具的打压力度只会越来越大，Shadowsocks最初的作者受到官方威胁已经是好几年前的事情，GitHub今年年初开始遇上间歇性干扰问题的时候，互联网信息服务管理办法修订还没见到正式确认下来，足以看出他们对于技术手段的传播问题之重视。不过中国毕竟还是需要依赖国际互联网进行科研、外贸、外宣等活动的，这规则似乎并不完美，因为规则当中似乎没有提到任何关于合资格个人或组织（例如跨国企业、外贸电子商务从事者、外宣官媒等）以合理目的获取合法途径访问被封锁网站相关的内容（不过近期有消息提到上海面向企业推出专用的国际互联网通道，广东和澳门在横琴岛建的合作区可以免翻墙，而北京似乎也开始允许向外资推出VPN服务），我等普通维基百科用户对于此条规则提意见，网信办当然不会采纳，不过那些跨国企业、外贸电子商务从事者、外宣官媒等等可就不一定了。鉴于目前仍在意见征集期内，现在我们还是静观其变吧。--🔨（留言） 2021年11月21日 (日) 09:09 (UTC) 说个和维基相关的，如果该条例最终通过，要不要禁止大陆管理员授予用户IPBE权限（某种意义上也算是为翻墙提供技术支持）？--忒有钱🌊塩水あります🐳（留言） 2021年11月30日 (二) 16:34 (UTC) IPBE是用来豁免维基百科为代理IP设置的编辑限制的，如果连WP都访问不了，给你IPBE也没用，这个其他用户先前就回答过了，而且自从基金会行动后，管理员人手现在已经比较吃紧了，当然居住在中国大陆的管理员本身在安全上就要有所顾虑，不管你是否有曾授予他人IPBE权限。一定要限制IPBE权限授予的话，最好视乎此条例具体执行情况再做进一步决定。--🔨（留言） 2021年12月11日 (六) 16:15 (UTC)

--Bovemdep（留言） 2024年10月3日 (四) 11:51 (UTC)

艾特一下之前讨论比较活跃的@Shizhao、AnYiLin、桐生ここ、不爱思考得猪、Cwek、忒有钱，请问你们有什么看法？--Bovemdep（留言） 2024年10月11日 (五) 11:58 (UTC)

已经解封

现在已经在中国解封，能够直接访问了。那么你们呢？--2408:8239:701:48E2:1C39:5BD3:BF21:B485（留言） 2024年12月18日 (三) 15:35 (UTC)

但是抽风了--2408:8239:701:48E2:1C39:5BD3:BF21:B485（留言） 2024年12月18日 (三) 16:14 (UTC)

没有啊？用SNI域前置倒是可以直连。--Haohaoh4（留言） 2025年1月2日 (四) 11:55 (UTC)