test1 发布的帖子

顺便说一句贵pkuanvil权重还挺高的:)

如题，本来搜“未名树洞 怎么了”只是想看看贵 pkuanvil 的搜索权重，结果发现另外一个树洞停办的帖子
https://ucaskernel.com/d/715

这篇文章没从内容角度分析（论坛有什么内容倾向，有那些经久不衰的核心话题，有哪些话题能激励用户引发讨论），比较遗憾。这个可能就只能在继续研究了。不过作者很明显非常熟悉高校社区的运营方法（作者举的例子里面，常规手段都到位了，没有缺少重要环节），然后也能发现论坛用户能翻X倍的关键节点。

后面锐评也不太想说，这个和 pkuanvil 的定位历史也有关系，在置顶帖里面也说的很清楚了。因为用户基础和站长的坚持，有些观念就很难讨论了，比如

正经的校园论坛，就应该和学校合作，放弃反审查的不合作思维（墙内审查不能接受，被查水表风险+发言束手束脚+主流叙事形成排他效应+……）
水源的指导老师梁女士曾说，要开屏即见正能量（这一点北大树洞有大量用户支持，但是我认为 BBS 不是脱离现实的真空区；不过作者后面补充的部分说的很好，要开屏就能留住用户，能够让用户有继续探索的欲望，特别是激发用户的参与。）
从触达上考虑，柠檬本身就在微信端内，只要有二维码就很好触达，也可以充分利用朋友圈转发（依赖非常封闭的平台特别是墙内平台）

“高校 BBS 论坛的运营”这一部分有些确实学不了，比如突发事件就不行：

9月的七彩花坊事件，直接带来了用户量翻倍。
22年3月，由于疫情封校，直接增加了5-10倍的日活量。在这期间，开辟了防控信息专楼，收集整理了每日最新进展，很多用户也以非官方身份发布了各种信息

另外整理资料也是辅助作用，效果并不佳。互联网并不缺少资料，更缺少交流。

资讯类的群聊的运营：

在运营C++学科辅导群时，……这样同学进群的时候就有东西可以看。……等到期末考试前，……所以这群名气出去了有很多同学愿意加群来听和问问题。
在运营选课交流群时，……这个PDF就对同学很有吸引力，我们把它放在群里。……禁止非选课事项的讨论、禁止询问明文通知的内容。……按时发布教务处关于选课的通知，提醒及时选课。……定期清理不改群昵称和长期没说话的同学。……整理出了400多条课程点评。

比较常规，（省略的部分其实不说也能猜到作者写什么）但是一条条都能清晰记录下来并且做到其实是不容易的

资讯类带互动的社区：

在运营选课社区时，最大的成功点就是之前整理的400条点评。我们在上线运营之前，就导入了这400多条问卷点评作为冷启动素材。这样用户访问的时候就能看到内容，而不会因为没有内容而流失。
在降低门槛方面，我也考虑了很多。比如，服务器一定要在境内，这样不会有网络问题。不能使用GitHub，因为要额外注册。接入jAccount实现一键登录访问。
在推广方面，在选课社区上线前，选课交流群已经发展到了2个2000人规模的群。我们在群里直接推广了社区链接。后来由于积累的点评很多，对新生很有价值，其他组织也会在其公众号上主动推广链接。
在促活方面，主要关注的是点评的数量和质量。选课社区引入了积分机制，根据点评数量和赞计算积分，而积分和交大传承合作，可以兑换传承的积分，从而在传承下载文档。

差异点在于不只是少数几个管理员中心式的输出，有用户的输入，不过也要重视冷启动。促活这方面我持保留意见，这个积分的其实奖励除非是已经熟知的硬通货（可能确实是？滚雪球效应体现了），否则用处不大。（北大的民间选课评价网需要认真学习这一段！）

高校 BBS 论坛的运营：

在运营水源社区时，主要抓的触达和促活。……逐步增加了blabla链接，看上去效果其实一般……不过今年有机会在交我办app的新生模块那加了个入口，效果非常明显，预估有70%的22级新生都注册了水源。
另外是抓热点事件，这种机遇比较难得。……我们趁着用户量增加的同时，及时调整了分类，主动编撰导入优质的信息资料（比如分流、转专业、保研等），增加了用户粘性。……开辟了防控信息专楼，收集整理了每日最新进展，很多用户也以非官方身份发布了各种信息。
一开始即便我们有jAccount登录，也要去验证邮箱获取验证码。……后来直接拿掉了这个流程，jAccount登录之后就直接进主页，实现一键登录。这一点在封校流量突增的时候表现非常好，没有拖后腿。
在促活方面，一开始首页按照传统论坛定为“分类”，但是我个人会喜欢以时间线排序不区分分类。后来有一次在用户建议下把全站用户的首页都改成了“最新”，日活立竿见影提高了5倍。

这个和我想的差不太多（预期之中），高校官方网站这些本身设计就不好，用户流量是很低的，谈不上引流作用。偏实用性质的效果会非常好，至少对新流量的引入是立竿见影的。

注册流程需要更加清晰简化。这一点 pkuanvil 做的不好，pkuanvil 虽然需要抵抗审查把流程设计的更复杂了，但是还是有改进空间。另外用户更喜欢被动收邮件而不是发邮件，这一点有技术约束成分（我不想强依赖一个 SMTP 服务器）。但是和 DKIM 注册相比还算好，绝大部分用户都没有错误, DKIM 注册的流程又难懂又不好操作，什么邮件能过也没说清楚。

促活方面没说怎么“内容激励”，只说了改变网站的设计，这一点我没感到惊讶，因为先前树洞的超高流量已经证明这一点。北大有大量用户（DAU 至少 5000 以上，近两年收归可能还要更高，大概能上万）都能接受“一天超过 5000 个新树洞，而且我还能一直往拼命翻到前一天”的模式。这在很多传统 BBS 看来是不可思议的，传统 BBS 一上来就分类，但是人是具有复杂的多面性的，其实更倾向于一条集中时间线的模式，在单主线基础上再细化分类

使用场景影响非常大，https://www.reddit.com/r/dumbclub/ 上面基本都是外国人，但是也普遍了解 v2ray 等等协议，如果没有 “跨越GFW” 这个需求的话就很难了解到

感谢，说的很好。
我认为自由是非常重要的，缺少自由的环境缺少的绝对不只是自由。但是现在用户似乎不普遍感受不到这一点（或者说不能自然而然地感受到这一点）。
小红书、朋友圈、qq空间，微博、微信等等都是墙内平台，本身就是重大缺陷。当然它们的优势也是很明显的。

不过尽管如此，我觉得这一段话说的很好，我一直以来都不太这么想：

能提供自由的平台并不少，这样的特色并不新颖也并不吸引用户。……实际上已经把自己定位成了这条赛道上的一个竞品，试问有什么理由能够让用户选择这样的一个平台呢？

telegram 有很多问题，不能控制服务端+是群聊不是BBS+注册需要手机号+……，等等。披露的话 telegram 记录倒是很良好。
不过有一段我不赞同：

邮箱系统最终还是由学校信息中心管理，想必大家也都明白我的意思吧，我就不多说了。所以，其实都不需要考虑什么内鬼了，技术上的安全性目前都没有做到

首先目前没有发现有高校在大规模的伪造用户的邮件。而且即使高校这样做，也不可能对所有域名都这么做。比如说如果北大计算中心批量发送注册邮件（目前的“通过发送邮件注册”的默认方法），这很容易被发现，我们可以要求用户用收到的，计算中心不能伪造的邮件来验证，即现有的 DKIM 注册方法。批量注册除了坐实自己在篡改用户邮件以外没什么用，站务不仅会删除所有这些伪造注册请求得到的账户，而且还会公开指责该高校的行为。
另外我没有看懂这位游客说的“我就不多说了”和“技术上的安全性目前都没有做到”。有青年研究中心的内鬼倒是没法避免，但是这只能代表一部分用户。而且以青研官僚主义的作风也就管管树洞，管一个类BBS平台发言都是公开的，你一翻它的发言，很容易看出它很可能是青研的。

用户增长理论之一：

用户增长，主要做几件事情：拉新、促活、内容激励。

• 拉新，指获得新用户，关注指标通常为DNU（daily new user）。
• 促活，指促进已注册用户活跃度，关注指标通常为DAU（daily active user）。
• 内容激励，指激励用户发布内容，间接增长DAU和DNU。

为了拉新促活，往往需要布置一些触点用来触达用户，比如弹窗、挂件、推送等。

这个没说阶段，但是我理解是推广初期的理论，主要针对外部吸引的新用户，用户粘性很低、流失率很高，加入网站时间也很短

用户增长理论之二：

除此之外，也有观点认为，用户增长=动力-阻力。

• 动力，指用户使用产品的动机，比如产品的内容对他有很大吸引力等。
• 阻力，指阻碍用户注册的因素，比如用户注册的流程繁琐等。

这个相对第一个理论阶段略微靠后一些，针对至少是听说过并且甚至可能访问过很多次的用户。
注意阻力不完全是客观条件（比如 需要付费/需要某地区的IP/需要某种身份/用户协议约束）造成的，也包含网站自身信息结构设计问题，对信息结构设计而言，动力和阻力是网站设计一体两面

原帖：https://blog.dujiajun.site/2022/10/17/当我在运营产品时，我在做什么？

读后感：

• 首先是觉得我 too young，感觉自己不知道要做什么
• 其次文章其实本身比较杂，作者大大小小的经验都说了，当然最重量级的肯定是交大官方的水源社区（基于 Discourse，仅限校内），不同社区群体的设计目标都差很多。最后也有一些旁观其他论坛后的评价。

然后摘录几个关键的句子吧，下面继续

现在DKIM注册有一部分是手动批准的，可能会有延迟，如果您觉得时间超过了预期请联系站务
pkuanvil@proton.me 或者用游客评论

抱起我忘记看DKIM注册请求了，但是现在我身边没带管理员权限，我尽可能晚上就处理您的注册请求

Reference: https://www.v2ex.com/t/852567

需要连接墙外能连上的 IP 地址，比如 https://www.cnbc.com 的 23.56.20.124 （注意下面评论提到 cloudflare 的 IP 被 SNI 阻断后会造成整个 IP 阻断，所以不要用 cloudflare 的测试，不过可以用 akamai 的 IP 测试：dig www.akamai.com），然后分别测试即可

openssl

没有 SNI 阻断

openssl s_client -connect 23.56.20.124:443 -servername abc123.com

这个和 v2ex 原帖的输出不一样，因为使用的不是 cloudflare 的 IP 地址，行为完全不同。23.56.20.124 目前对错误的 SNI 也会有 TLS 连接，正常 TLS 连接的输出很长，就不一一列出了，可以看到 TLS 证书的被签名的域名

depth=0 C = US, ST = New Jersey, L = Englewood, O = "NBCUniversal Media, LLC", CN = *.cnbc.com

有 SNI 阻断

openssl s_client -connect 23.56.20.124:443 -servername twitter.com

什么都没有，TLS 握手读取到 0个字节，当然也没有 TLS 证书

no peer certificate available
SSL handshake has read 0 bytes and written 315 bytes

curl

没有 SNI 阻断

curl --resolve abc123.com:443:23.56.20.124 https://abc123.com -iv

建立了 TLS 连接，不过 curl 认为和 https:// 的域名不符，拒绝连接

* Server certificate:
*  subject: C=US; ST=New Jersey; L=Englewood; O=NBCUniversal Media, LLC; CN=*.cnbc.com
*  start date: Oct  1 00:00:00 2023 GMT
*  expire date: Oct  1 23:59:59 2024 GMT
*  subjectAltName does not match abc123.com
* SSL: no alternative certificate subject name matches target host name 'abc123.com'

有 SNI 阻断

curl --resolve twitter.com:443:23.56.20.124 https://twitter.com -iv

什么都没有，除了来自 GFW 的 RST

* Recv failure: Connection reset by peer

@butterbot

把chrome的路径直接改了，强行改成没空格的，试了一下，也没翻墙功能，唯一能连上的github也不确定是不是脚本的作用

试试访问这两个链接，能访问 https://gist.github.com 和 https://raw.githubusercontent.com 就表示脚本有效，因为这两个域名都被墙了
git ssh 代理设置
cloudflare反向代理

感谢回复。

免费节点也已经泛滥，无论是技术、经济还是使用体验，似乎没有什么理由需要使用您的方法。

这个我部分程度同意，但是总有场合（或者说总有一部分用户）是缺少好的翻墙手段的。而本贴介绍的方法只需要下载这些文件然后加到 chrome 命令行里面就行，我觉得至少算是一种低门槛的备选方案

希望您能够列举哪些网站可用，以及可用性如何

可用的网站都写在 rules.json 文件里面了。

使用 fastly CDN 的几个（reddit, pinterest, twitch）应该一定可用，只要你能直连 https://fastly.com 本身。就像前面说的，如果 rules.json 给出的 IP 地址 151.101.1.57 连不上，但是 https://fastly.com 能直连的话，只要把 151.101.1.57 替换成任何一个 fastly 的 IP 地址就行，比如换本地 DNS 解析 fastly.com 的 IP 地址。
本质上是一个优选 CDN IP 地址的问题，可能需要开新话题讨论+参考更多的文献，我也不太懂。

使用 netlify CDN （https://docs.rsshub.app）和 gcore CDN（https://pkuanvil.com）的同理，

用这几个 CDN 的网站的可用性很高，只要你能直连这些 CDN 的官网，可以做到无缝连接。

wikipedia.org, web.archive.org 和 torproject.org 就只能随缘了，因为这几个不走 CDN 而且 IP 地址本身速度很慢（限速甚至断流）。

github 也是不走 CDN 的，但是它的 IP 限速情况会好一些，有些地区 IP 地址本身没限速只是检测 SNI 以后做限速。此外使用脚本做 SNI 伪装以后也可以正常访问被墙的 https://raw.githubusercontent.com/ 和 https://gist.github.com/

总结：从能连上的角度来说，可用性 (fastly, netlify, gcore) CDN > github > wikipedia.org, web.archive.org, torproject.org (and others)

从使用角度来说，我简单做了测试，写到 rules.json 里面的常见功能应该都没问题。（有些网站没加是因为它们的子域名都用的不同的CDN，还没逐一调试）

一个方法可能在您所在的地区可以用，不代表其他地区的人也可以用

这个也是 IP 地址能否连上的问题，这就只能依靠大家反馈了。但是这种反馈也很粗略（用户为了保护自己隐私，能说到道省一级的那个运营商就不错了），难以测试。
作为我 pkuanvil-uid1 来说，可能可以做的是给一堆 IP 地址然后逐一尝试，现在的话能连上 rules.json 里面的 IP 地址就能连上，不能就不能……

https://www.reddit.com/r/dumbclub/
简单扫了几个帖子，多数都是来中国大陆旅游或者留学发的帖子
“讨论选什么 VPN 和绕过 GFW 的其他方法的地方”

@butterbot 加双引号就行，前面忘记改了
return r'"C:\Program Files\Google\Chrome\Application\chrome.exe"'

@butterbot 可以试试把 rules.json 里面和 fastly.com 那一栏对应的 IP 地址，那个会在整个文件里面重复很多遍，都替换成本地使用的 IP 地址，比如 Powershell 查询 fastly.com 的 IP 地址：Resolve-DnsName -Name fastly.com

如果 fastly.com 本身能连上的话，用 fastly CDN 的网站都应该能连上，比如 reddit
netlify CDN 也是同理，应该能连上 https://docs.rsshub.app

其他的网站我就不太好说了