使用 VLC 举办在线观影活动

上一篇讲了使用 SyncPlay 和朋友一起看电影的办法。这篇讲一讲使用 VLC 串流播放电影的办法。

大体来说，这种办法类似于以前一度流行的网络电台。一个主持人负责开设视频流服务器，其它人连上去即可收看。主持人这边的配置略需要折腾，但参与者那边是比较轻松的，只要往播放器里填一个地址就行。用这种方法和朋友分享电影也有一些缺点。除去主持人这边设置有些门槛（本文就意在消除这种门槛）外，对网络条件要求颇高，要是有几十个朋友一起看的话，恐怕谁家的网络都支撑不住，只适合三五好友一起观影。虽然说播放进度是同步的，但是主持人按播放和暂停之后，都要等小一会儿所有人的屏幕才会有反应，这种延迟也是其它方法没有的。

VLC 是一款很流行的开源媒体播放器。本来叫作 VideoLAN Client，从名字可以看出 VideoLAN 这个计划本来是为了提供一套在网上串流分享视频的工具，播放器只是它的 client 端。后来它的 client 端使用的人越来越多，其 server 端的功能也被整合到播放器里，播放器遂改名为 VLC Player。

整合之后，VLC 的在线串流功能和转码功能是做在一起的。在线串流不过是转码的一个特殊应用——区别仅仅是输出。转码的输出是文件，而串流的输出是一个网络视频流。这项功能的使用并不复杂，界面也还算简单，唯一不好的地方是，虽说顺的时候很顺，一路鼠标点点点就可以过去，可是有时候也会掉坑，想从坑里爬出来的话就需要点技术知识，自带的帮助实在不算友好。

所以写这篇短文介绍一下基本操作和常见的坑。

基本操作

基本操作网上图文教程很多，就不写太细了。

启动 VLC 之后，Media 菜单选择 Stream，弹出 Open Media 对话框，按 Add 按钮添加需要播放的视频文件。如果电影文件不止一个，可以依次添加。然后按 Stream 按钮开始串流设置向导。
点 Next，出现协议选择对话框。一般选择 HTTP 协议，然后点击 add 按钮。端口和路径可以使用默认值，也可以自行修改。
下一步是转码设置。可以选择转码或者不转码。这是最容易掉坑的地方，下文详细讨论。一般来说，如果收看的人网络条件都不错，不想占用 CPU 的话就不要转码。
最后确认所有参数并点击 stream 按钮，VLC 会开始播放视频，但是窗口是黑色的。此时可以在另一个 VLC 或者其它播放器中打开 http://IP地址:端口号 来访问以验证服务是否启动成功。将此地址分享给朋友之后，朋友就可以在视频播放器上使用此地址观看视频
在播放时，只有主持人可以拖拉进度条、播放和暂停。其它人只能选择看或者不看。需要一起语音聊天讨论剧情的话，另外开一个语音聊天软件就可以。

也可以通过命令行的方式来启动服务，复制第4步中显示的命令行参数并保存，即可在下次使用命令行直接启动服务。命令行大致形如： vlc 文件名转码输出参数

官方的帮助见 Streaming HowTo New

FAQ

如何获得用于分享给别人的播放地址？
播放地址分为两部分。一个是 IP 地址或者域名，一个是端口号。
如果服务端和播放端都在同一个局域网，或者服务端有公网 IP，那么直接使用服务端的 IP 地址即可。Windows 下可以在 cmd 中敲 ipconfig 获得 IP 地址。Linux 下可以用 ip a 命令查看 IP 地址。有自己域名的人可以把域名绑定到 IP 上方便记忆。不过我想有域名的人都不需要人教如何查看 IP 地址。
如果服务端在路由器后面的话，参见下面一个问题。
端口号就是第2步所填写的端口号。默认是 8080。
电脑在路由器后面怎么办？

如果运行服务的电脑在路由器后面，播放视频的朋友不在同一个网段，就得配置端口转发。当然如果就是在自己家里播放，自己家里收看，无须做端口转发。
登入路由器的管理界面之后，设置一条端口转发规则，将一个对外的 TCP 端口A转发到自己开设服务的电脑上 VLC 所侦听的端口B。B端口就是第2步所设置的端口，默认是 8080。
填写端口转发规则时，对外端口可以随便填，推荐大于 1024，但是不能大于 65535。转发的目标 IP 如前一问所述，可以通过 ipconfig 或者 ip 命令查看。

在和人分享播放地址时，IP地址要填写自己路由器的公网地址（可以通过访问各种显示当前 IP 的网站来查看自己的 IP。比如说直接在 Google 里搜索 “My IP address”，Google 就会告诉你。），端口号要填写被转发的端口A，而不要填写端口B。
什么时候需要转码？

转码会占用相当的 CPU 资源。所以如无必要可以不转码。
视频码率太高，以至于网络无法负载，视频严重卡顿的时候需要转码。
照前述基本操作步骤无法观看视频的时候有可能是视频或音频格式不兼容，此时可以试试转码看能否解决问题。值得一提的是 DTS 音轨不支持串流，必须转码。
蓝光原盘兼具码率过高和 DTS 音轨两个问题，必须转码。详见下节的讨论
可以使用 HTTP 之外的协议吗？

可以。VLC 提供的各种串流选项都可以用。只是 HTTP 用的最多，兼容性最强。
可以挂字幕吗？

原则上可以。在第3步转码选项中有字幕选项。字幕有软硬两种（英文说法是 Closed Caption 和 Open Caption）。软字幕指的是播放者可以自行决定字幕开关，而硬字幕是直接修改了视频画面。
软字幕有两种格式选择，硬字幕选项通过勾选 “Overlay subtitles on the video” 实现。

我没发现任何一种软字幕选项可以在 VLC 客户端播放，可能有些格式可以在智能电视上播放，但我没有测试。
如上述，VLC 支持在转码的同时将字幕硬压到视频流中。如果要这样做的话，必须选择对视频进行转码。硬压的字幕只有主持人可以选择字幕，其它人只能接受主持人选择的字幕。主持人在播放时正常在窗口中右键选择字幕即可。
如何实时监视播出效果？

实时监视播放效果是必须的。不然岂不是只给别人放电影，自己只能盯着黑屏幕，比电影放映员还惨。
有两个办法。一个是第4步提到的，再开一个 VLC 窗口，填上播放地址之后进行收看。优点是可以确保自己看到的效果和其它观众看到的效果一模一样。缺点是设置不当的话会占用自己的网络带宽，可以同时支持的观众数目减一。
另一个办法是在第2步添加 HTTP 协议的时候，勾选 “Display locally”。优点是不会占用网络带宽，缺点是体会不到其它观众的延迟（扶额，这也许不是缺点，只是不能与民同乐）。此外有时会有不明故障，明明别人都可以正常收看，自己却无法看到图像。

几个特殊问题

如果按以上步骤操作一切顺利，读者无需查看此节。这里只对一些特殊问题给出解答。

转码的参数设置

在第3步中，VLC 有几个预设好的转码方案。通常来说，第一个 H264 视频/MP3 音频/MP4 封装的选项具有最好的兼容性。也可以根据需要选用其中其它的预设。

如果要修改某个预设，按扳手图标；如果要新增预设，按最右的图标。

视频转码非常消耗 CPU，如果只有音频格式不兼容需要转码，视频不想动的话，可以新建一个仅对音频转码的预设。也可以直接在第4步的命令行参数中删掉 vcodec 选项。

特别需要指出的是，很多时候音频流不仅要看编码，也要看采样率。至少，在很多时候对于来自光盘的 DTS 和 AC3 音轨，使用默认的 44.1kHz 采样率无法正确编解码，需要改为 48kHz 才能让观众正常收听。

视频编码推荐 H264，因为兼容性良好而且相对于 H265 更节省 CPU。如果自信自己的机器性能非常强大，所有观众的播放软件都足够新，可以使用 H265 编码以节约网络带宽。但该 GUI 界面并不能指定使用多少线程进行编码，如有必要用到 CPU 的全部能力，需要在命令行中指定线程数，参见官方帮助和示例。
视频码率可以不填，VLC 会自动选择一个画质损失不大的码率。视频质量之类的参数不必深究，VLC 使用 FFmpeg 进行编解码，若需要全面了解其参数选项建议研读 FFmpeg 的帮助。

音频编码一般来说 MPEG4/AAC 就足够好了，而且兼容性很好，几乎所有设备都可以播放。MP3、AC3 之类的格式都有点太老了。其它新格式的兼容性不如 AAC。码率可根据个人对音质的要求酌情选择。

蓝光原盘的推荐设置

当源文件为蓝光原盘时，必须转码。原因有二，首先是 DTS 格式音轨无法串流必须做音频转码；其次码率过高，大部分情况下网络无法流畅播放。

蓝光原盘的音轨大多为多声道 DTS 格式。音频转码的时候必须选择 48kHz 采样率，否则没有声音。
也许有人觉得自己网络条件非常好，想只对音频转码而保持视频不转码，但这会遇到严重的音画不同步问题，非常不建议这样做。

软字幕无法正常传送到其它 VLC 客户端，需要在第3步选择将字幕硬压到视频流中。参见 FAQ 第5问的解答。

当然实时转码的话，未免有点损失画质，使用蓝光原盘作为源文件的优点也就没有了。如果希望有比实时转码更好一点的画质的话，建议事先转码，串流播放的时候不转码。
事前转码可以继续用 VLC。但若希望仔细调节码率和画质参数，建议研究FFmpeg，直接使用 FFmpeg 丰富的参数进行定制。懒得研究 FFmpeg 的话，可以使用 HandBrake 这一 FFmpeg 的 GUI 界面。HandBrake 内置了许多预设，可以直接套用。

和朋友一起看电影系列

使用 SyncPlay 和异地朋友一起看电影
 使用 VLC 举办在线观影活动

使用 SyncPlay 和异地朋友一起看电影

近日疫情致令本州下了居家令。不过在居家令之前，本也不敢出门了。线下社交完全停滞，就和朋友们约着在线上一起做些事情。比如线上的 movie night。今晚成功举行了第一次，大家聊得很开心。这里是一份实操指南。和我以前写的指南风格不同，为了将来邀请不那么懂技术的朋友一起看电影，会写得很详细。

在开始正文之前，先列举一下各种在线一起看电影的方法。大致来说，需要两种工具。一种用来同步所有人的播放进度条，方便有人去喝水上厕所时大家聊天等待。另一种用于语音聊天。后者没什么可说的，前者才是难点，可惜并没有什么可以通吃所有视频的方案。

对于 Netflix、Youtube、Amazon Prime 乃至优酷、爱奇艺、B 站等国内视频网站，有许多浏览器插件可以用于同步播放进度。
目前 Amazon Prime、Hulu 已经官方提供了 Watch Party 功能（于 2021 年 3 月更新此条）
对于本地文件，有两种方案
- 一种是我们今天晚上所采用的，每个人在各自电脑上播放视频，使用软件同步播放进度。这是今天的主题
- 一种是由一个人设置 video streaming server，其它人连上去观看。以前常用 Winamp、foobar2000 来开设或收听 ShoutCast 网络电台的人对此一定不会陌生。就是在网络电台中播放视频罢了。如何使用 VLC 来开设「网络电视台」我会另文详述。Plex 和 Kodi 也可以用来这么干，但是这些 Media Center PC 的解决方案未免太重型了。
还有的观影 app 或者服务本身支持多人一起在线观看电影。有些已经死了，现在有一个叫微光的 app 还活着。倒是「虚拟电影院」类的 VR 软件颇为不少，有 VR 头显的人可以试试。

有一篇不错的英文文章总结了各种工具。其中对于中文互联网常见工具欠奉。比如说，有一个叫 Coplay 的 Firefox/Chrome 插件支持常见的国内视频网站。

好了，开始正题。SyncPlay 是一个跨平台的用于同步各自电脑上视频播放进度的开源软件。支持 Windows Mac Linux *BSD。

使用 SyncPlay 来一起看电影的话，需要如下条件。如果不能满足的话，或应考虑换别的方法一起看电影

将待播放的视频文件预先分发给每一个人。在海外 DropBox 的速度相当不错，国内就得另想办法了。
在每个人的电脑上安装 SyncPlay （不想安装可以用绿色版）
保证每个人的电脑上有至少一个 SyncPlay 支持的视频播放器，比如说 VLC、MPC、mpv。没有的话需要装一个。
准备一个用于语音聊天的平台，用电话、微信、QQ 还是 Skype、Zoom 都无所谓。就我有限的体验来看，似乎跨国视频还是 Zoom 最流畅。
最后是一句废话：需要有一台能上网的电脑。但对网速没有要求

作为最佳实践，在观影活动开始之前，多人观影活动的主持者需要做如下事情

用 Google Docs 或者类似的在线文档平台创建一个公告板，用于汇总本次观影活动的信息。微信群聊的大水很容易淹没通知信息，所以需要一个专门的公告板
将视频文件上传到一个网盘上
在公告板上列出如下信息
- 放映活动的时间
- 视频文件的下载地址
- SyncPlay 的服务器地址和房间名称。
  如果不打算自建服务器的话，可以使用 SyncPlay 官方提供的四个服务器地址。需要详细到端口号（不同端口是不同的服务器）。房间名称可由活动组织者指定任意字词，只要大家都在一个服务器上的一个房间即可同步
- 语音聊天所用的平台和加入的方法。
  比如说使用 Zoom 的话可贴出 Zoom 链接
其它步骤与普通参与者相同

作为最佳实践，观影活动的参与者需要做的事情如下

查看组织者所发布的活动公告，并下载视频文件
如果希望自己晚到时别人等一下自己，可在公告板上留下自己的名字
安装 SyncPlay 和一个 SyncPlay 所支持的视频播放器。如已安装可跳过此步
在活动开始前几分钟，关闭电脑上的其它视频播放器窗口，打开 SyncPlay，在其界面中依次填写下列各项
- Server address 填写活动公告给出的服务器地址
- Default room 填写活动公告给出的房间名
- Username 可不填，推荐填写一个方便别人认出自己的名字
- 如果已经安装了支持的播放器，”Path to media player” 一项应该已经自动填好。如果安装了多个播放器，选一个自己喜欢的。
点击 “Store configuration and run SyncPlay” 按钮，会弹出一个视频播放器窗口。将准备一起看的视频文件拖入该视频播放器窗口中（而不是 SyncPlay 窗口中）。此时 SyncPlay 窗口右半边显示房间中已有的用户和每个用户播放器中的文件名。请保证自己的用户名后面显示了视频文件名，而非空白。如果不是这样，请重复第 4 步和第 5 步，可能是未关闭所有已有视频窗口。
连上语音/视频聊天平台，和所有人打个招呼
人到齐之后，每个人都勾选 SyncPlay 窗口右下角的 “I’m ready to watch”。然后任意一个人点击视频播放器的播放按钮，所有人的视频就会同步开始播放。
视频开始播放后，使用音箱的观众应将自己语音聊天的麦克风关闭，以免形成回声。使用耳机的用户不需要闭麦。觉得自己这边环境太吵的人也应当主动闭麦。
如果使用 Zoom 群聊，将 Zoom 视频窗口最小化，它会自动生成一个悬浮窗。视频全屏播放时不会遮挡这个悬浮窗，方便在看电影时控制自己的麦克风。
如果麦克风常开，不需要 Zoom 悬浮窗，也不希望视频被 Zoom 的悬浮窗所遮挡，那么不要最小化 Zoom 窗口，直接让播放器全屏即可
在开口说话之前，看一眼自己的麦克风是否已经关闭。如果关闭的话，先打开麦克风再讲话
如果需要离开片刻，可以在剧情不紧张的时候按下暂停，和朋友们解释一下后离开。其它人的视频也会暂停，可以用这个时间讨论剧情或者闲聊。

观影活动结束后，建议主持者删除网盘上的视频文件，以保护自身隐私。

总体来说，SyncPlay 这套方案优点很多

完美的跨平台支持，所有人都可以用
对网络条件要求很低
因为视频文件在本地播放，可以有很好的画质
非常稳定，很少出问题
开源软件，可以选择自建服务器，不用担心隐私泄露

但也有一些缺点

每个人都需要下载视频文件。这并不方便，也不总是可行。
需要安装 SyncPlay，略麻烦了一点
语音群聊的时候使用音箱观影的人大部分时候需要闭麦
弹幕功能仅支持 mpv 播放器，所以主要还是和语音群聊搭配使用

和朋友一起看电影系列

使用 SyncPlay 和异地朋友一起看电影
 使用 VLC 举办在线观影活动

宅在家里干点啥

国内的疫情局势已经稳定，现在旅居海外的中国人开始和欧美各国人民一起享受禁足宅家的“乐趣”。在家里呆着干点啥呢？询问了一下已经在家里蹲了俩月的国内朋友，发现大家干的有意思的事情还是不少的。

遥想上次因为 SARS 而放假还是初中的时候，那时候颇是过了段快乐的日子。成天自以为是地鼓捣点实验，翻书以为自己做出了什么惊人发现，天气晴好的时候搬着望远镜看星星看月亮，遥望着喜欢的女孩的背影发呆，把老师布置的假期作业用放大镜烧出“垃圾”两个字交了上去却被课代表庇护而没有报告老师。不知道这段时间的禁足会做点什么事情呢？

这篇更多地是一篇写给自己看的东西，算是立些 flags 罢。大概最后不免沮丧地发现大部分预订的目标还是一如既往地没有完成。不过读者倘使有什么好的建议的话，欢迎告诉我。

第一个小目标还是定个容易实现一点的吧：每天不要刷疫情新闻了。现在局势已经日趋明朗：各国都在根据国情努力找到让本国卫生系统不崩溃的办法。如果不打算做点什么的话，安心宅家里就是你好我好大家好。如果实在是精力过剩手头没事干，就去找找什么纾解疫情的活动还缺志愿者。

第二个小目标是放下手机。反正不出门，什么都可以在电脑上完成，正好戒一戒手机依赖症。当然电脑也最好少开几个窗口，专心做点事情。

第三个目标是读一些平时没有时间或者心情读的书。有些平时静不下心看的电影或者戏剧也适合这时候去看看。少看不看知乎和各种已经一泡污的中文 SNS。这两天在看维也纳国家歌剧院和纽约大都会歌剧院的“尼伯龙根的指环”。两家剧院都因应疫情而免费放出历史录像，观后颇有余音绕梁之感，只恨年年惊蛰春分前后总是睡不足，难得有十足精力去尽情领会其中妙味。

第四个目标是每天写点东西。或许是些论文报告之类的“有用”玩意，或者是和友人的邮件闲扯之类的无用文字，思有所得便尽量记下些东西来。年岁日长，记忆日差，大概不能像以前一样把一些主意只是存在脑中在数年中慢慢推演了。

第五个目标是给久未联系的朋友们打个电话聊聊天。与其在手机上和不相干的人就不相干的事情瞎扯斗气，不如和关心的人谈谈人生感悟。

第六个目标是把一些搁置已久的个人小项目完成几个。

最后立一个明知不太可能完成的目标罢：早睡早起。眼见得今天又不能早睡了，哈哈。也不知道这七个目标最后能完成多少。

删文机制的技术讨论

本文包含虚构，如有雷同，也许有巧合。主要讨论相关技术，读者请勿过度联想。

前两天，在某国某知名 app 上，大量网友使用不同方式接力转发一篇“发勺子的人”。然而无论网友用什么办法，图片、竖排、旋转还是译成其它语言，都旋发旋禁。之后有一篇评述此事件的文章“今天是XXXX诞生以来最荒谬的一天”广为流传。

关于此事，解读很多，其中不乏有大胆创新、思路开阔、老成谋国、演绎非凡的观点。我等既不大胆，也没有思路，年纪不老，更没有多少演绎能力，所做出的推测，原本是最无足奇的。不揣冒昧，以飨读者。

据野叟村言，某知名 app 长期与某某、某某知名学府合作，效唐朝大案牍术遗智，建造了一套“‘威行’风闻系统”。无论什么文章、图片，皆可实时显示其传播踪迹。使用机器学习技术，深入分析造成舆情的文章的文字特征与传播规律。

根据这套系统训练学习的结果，某些用户向来最喜欢分享某类文章；某些文章如果在初期具有某种传播趋势（比如被看到之后转发率极高），就很可能大规模传播。布希大统领有言“先发制人”。待到舆情形成，就已经晚了。这套系统可以在不识别文章内容的情况下，仅从文章传播规律分析，就预判内容是否可能造成舆情，予以预防性封禁，待人工审核定夺。比爱国者导弹什么的高到不知哪里去了。

以多种形式被传播的“发勺子的人”一文，就因读者一见即转，屡屡触发自动封禁。追究起来，只是机器系统的一次日常作业。人工审核者们只是系统的一个螺丝钉，滥放文章或许有责任，滥封文章集体无责任，看到机器系统报上来的文章，自然本着“应封尽封”的生存精神，一律拿下。所有网友殚精竭虑创作的图片艺术，只增加了他们几秒钟的工作量，就变成了晚间“今日舆情分析报告”里的一个数字。

有司根据“今日舆情分析报告”下令对此类消息一律放行，已经是几小时之后的事情了。“今天是XXXX诞生以来最荒谬的一天”就在这个时候发出，因而尽管转发众多，完全没有被删的迹象。

某计算机安全专家表示，这套基于传播规律的封禁系统虽然对于内容不敏感，封禁效率高，开销少，但仍然存在可被攻击的弱点。该专家构造弱点如下：假定存在一种机制，使得每个读者在转发时重新构造一条与原消息哈希摘要不同的消息，则该系统将无法追踪内容的转发，自然无法工作。当然，仅仅在转发时扰乱消息是不够的，消息必须在转发过程中保持人类可读。

对于这种攻击，假定消息以图片形式发出，有几种可能的实现方法。

图片添加随机扰动。在消息中醒目标示请读者在转发之前访问某网站以获取新的随机扰动图片。此种攻击的缺点在于，用于生成新图片的网站是其薄弱环节。
图片添加伪随机扰动，随机数种子在图片中附上。用户端安装软件自动解出随机数种子，反卷积得到原始图片，二次加扰后将新随机数种子附在新图片中发出。此种攻击的缺点在于，封禁系统一方得到这套算法后就可以轻易破解。
理想情况下，构造一种添加随机扰动的方法，在无穷多次添加扰动之后，信息仍然可读。目前还不知道有这种算法，它也许是存在的。
不可逆伪随机扰动。使用一种算法构建一组 mask：m1、m2、m3 乃至于 mN。N足够大，足够所有人转发使用。得到一张被 mask 的图片之后，并不知道 mask 本身是什么，也无法解出原图片，但可以依特定算法算出被 m(n+1) 所 mask 后的图片是什么。每个用户收到图片之后，向前迭代任意步后转发即可。这个的构造并不难，留给读者做思考题。因为 N 足够大，所以封禁系统一方不可能遍历所有可能 mask 并生成其哈希摘要。

Mar 9 2020 digest

设立这个系列是因为我有两个讨厌的毛病，一个是经常修改文章，另一个是经常在东西写好很久之后再上传到博客，并把时间倒标为写好时的时间。这使得 RSS 订阅者难以获得最新信息。因而准备不定期地列举一下博客近期的修改，供读者取阅

另一个目的是分享一下近期遇到或者学到的有趣东西，也许它们过于简短，不足成篇，索性在这里全倒出来好了。

近期更新

告别删文：在哪里写博客？在发布之后又做了一些更新。
Update on March 8th 2020: 增加了 netlify, GAE 和“长期可持续性”评价
Update on March 7th 2020: 增加了 docker 部署
Update on March 5th 2020: 接受了 atreides 的修改意见，增加了不同评价标准的横向比较评价，增加大量脚注和 Tips，重写了自建站点和静态博客两章
这篇文章一万七千字啦，我觉得对于新手来说应该算是很全面的一篇指南了。希望能帮到有需要的人。文章地址不会变，可以放心收藏网址。

预防封号：备用联系方式的选择更新了注册马甲相关事项

搬运了一篇在知乎上的旧文，并做了一些补充
GPG SKS 同步网络被投毒事件及其影响

从原博客或者我的草稿箱里搬运了如下博文
关于文本编辑器的一点想法
 杂感一则：中文互联网知识获取越来越难
 Netflix与中美在线视频市场
 近来观影有感
 驳施一公“大学不该谈就业”
为什么要支持电子书破解DRM
如何由一滴水推断出尼亚加拉大瀑布的存在
 浅论电池选购

还有五六篇搬运的内容不大有趣，大多是具体技术问题的技巧说明一类，就不劳烦读者去看了。

近期的有趣东西

如我在告别删文：在哪里写博客？中提到的，GitHub Actions 实在是个有趣的东西。给免费用户的额度也实在可称慷慨。简单地说，GitHub 允许用户定义在 push 代码之后自动做什么东西。用户可以在 GitHub 上部署虚拟机完成编译部署或者其它能想到的自动化玩法，比如说邮件推送什么的。可以玩的东西是无限的，难得的是免费。

Feedly 看样子对我这种不常更新又没读者的博客不怎么友好，抓取不够及时。TTRSS 是个好东西，自己部署RSS服务器，抓取频率自己说了算——为什么不直接用RSS客户端而要用它呢？当然是为了多设备阅读同步啦。家里有公网IP地址的话部署在家里也很方便。

另一个发现我也写在博文中了，就是大部分GitHub部署的静态博客，博主本人都不知道其实是有RSS的。只需要在站点URL后面加上/feed.xml就可以了

开始试用免费版 diigo。也许哪天会写一篇关于它的文章。

我有几篇欠了很久的在这个数字时代我们应该如何做好个人安全防护的文章没有写好，草稿堆的都有几万字了。希望今年能写完发出来。

争取以后每周给大家推荐点最近看到的有趣东西。

新冠病毒看样子要全球大流行。大家保重。

告别删文：在哪里写博客？

本文意在比较几种值得推荐的热门博客方案。包括自建 WordPress 博客站、GitHub 静态博客、Blogger 和 WordPress.com 等。主要面对还在几种技术方案之间进行犹豫的人，已经搭好博客的人也可以在考虑备份博客站时用以参考。因为每种方案在网上都有很多详尽的教程，本文不对具体搭建过程做详细的逐步解说。但对于通常教程中未提及的部分，以 Tips 的方式补充说明。只看结论的话拖到最末即可。

为照顾没有技术基础的读者，本文使用脚注对一些词语做了注解，可点击相应链接跳转脚注和跳回原文。如果您觉得本文尚有未尽或难懂之处，欢迎在评论区留言，在 GitHub 上提 Issue，或者对这个文件发 PR。

感谢 atreides 对本文的批评和贡献。

CHANGELOG:
Update on April 8th 2020: 增加了「广告收入」评价，补充了托管型 VPS
Update on March 8th 2020: 增加了 netlify, GAE 和「长期可持续性」评价
Update on March 7th 2020: 增加了 docker 部署
Update on March 5th 2020: 接受了 atreides 的修改意见，增加了不同评价标准的横向比较评价，增加大量脚注和 Tips，重写了自建站点和静态博客两章

自主博客

在这系列文章的开篇中，我提到，要想保证自己对于自己产出的文字有绝对的控制权，一个自主博客¹站点是最可靠的文字存档所在地。先定义一下这里我们所说的自主博客：

自主博客

所谓自主博客，是指博客的作者对于一切内容和内容的呈现形式和传播方式拥有最终决定权的博客。

对于内容具有决定权意味着数据完全属于作者，其创作与修改不受其它人的干涉，数据可以不受限制地导入导出；
对于呈现形式具有决定权不仅包括对于博客页面排版风格的决定权，也包括内容是否可以依作者的意愿以完整或不完整的形式发布；
对于传播方式拥有决定权意味着博客内容 URL 的控制权属于作者，作者可以决定内容以公开或非公开的方式发布，可以自由选择 RSS 等网页之外的传播渠道。

为什么这些条件很重要呢？

对内容的控制权，意味着，平台（博客服务提供方等）不能够随意删除和修改作者的文章；
对呈现方式的控制权，意味着，平台不能随意隐藏内容；
对传播方式的控制权，意味着平台不能随意停止内容的访问，不能随意破坏我们分享出去的链接。

在最坏的情况下，即使整个平台停止服务，作者也可以导出所有数据到其它平台并重定向 URL² 到新的博客上。如果要保证我们的表达能以我们想要的方式被人听见，这些都是非常重要的。不用说，公众号、头条号、百家号等平台一条都不符合。

因而，当选择一个准备安心写上几年的博客平台的时候，我们为了内容的控制权，应该注意下面这些条件：

是否支持绑定作者自己拥有的域名³。域名在作者手中意味着在切换平台后可以将原有文章的所有链接指向新的平台。没有自己的域名的话，搬家之后原来文章的网上声誉和链接就要从头来过
- 同样重要的一点是，是否允许作者决定文章的静态链接的形式⁴
是否提供方便的数据导入导出。许多平台为了吃住作者而故意不提供数据导出功能
是否存在删禁文章和帐户的情况，如果有，其标准是否公开透明，申诉机制是否及时有效

现在还愿意安安静静写博客的人越来越少了，其中大部分人年龄已经大到看惯了互联网服务的沧海桑田。就博客来说，国内当年用户颇多的网易博客和百度空间都已经关闭。新浪博客也长期处于疏于维护的半死不活状态。没有什么服务会是永远开放的，写了几年的博客一朝关闭数据却不能迁出是非常打击人的一件事——许多朋友都因此封笔。就算不为了防止自己辛苦写好的东西被删，哪怕是为了预防平台关站，选择自主博客方案也是非常重要的一件事。

当然，即使是当年博客在中国还非常火爆的时候，大部分博客服务提供商也是不符合上述条件的。如果读者最近准备新开或者是重开博客的话，选择自主博客吧。就不要和那些风烛残年的新浪博客之流浪费时间了。

博客方案的选择

那么，现在还有哪些好的自主博客选择呢？

自己架设一个服务器是最彻底的方案
近来使用 GitHub Pages 来发布一个静态博客也是相当流行的选择
使用 WordPress.com 或者 Blogger 之类的有节操的大型博客服务商
使用 Bitcron 之类的小众博客服务商

下面从上手容易程度、费用、访问性能、用户群体等方面来详细比较这几种方案，简单提示一些容易踩的坑，并在最后给出不同人群的推荐。

不同方案的对比

自建博客

自建博客，顾名思义就是站长自己买服务器，自己安装博客框架或程序，因而对于博客服务端具有较完整的控制权。服务器的选择有 VPS⁵、虚拟主机⁶等，博客程序的选择有 WordPress、Typecho、Joomla!、Drupal 和静态博客等。其中 WordPress+VPS 是目前绝大部分人所采用的方案。大概情况如下表

方面	评价
技术门槛	较低
费用	60 美元/年
访问性能	一般或较差

自建 WordPress+VPS 站点原本是需要一些 Linux、HTTP 服务器、MySQL 和 php 设置的知识的（如果不需要自己高度定制的话，并不需要学习 php）。但是现在各种一键安装包很多、照着教程一路搞下去还是很容易的。只是没有相关知识的话进行一些设置的时候可能会找半天不知道问题在哪里。然而现在有一类托管型 VPS⁷可以让 VPS 也不那么折腾。读者可参见 WP 叔叔的这篇文章中的介绍。

价格的话，一线 VPS 服务商如 Linode、DigitalOcean、Vultr 等的最低配服务器基本都是 5 美元每月。对于一个流量不大的个人网站来说绰绰有余。在这几个自主博客方案中算是比较贵的方案了。

可是只买一台服务器的话，访问性能其实是不大理想的，一来总会有访客到服务器的距离比较远，二来国内的网络环境比较复杂，有些地区的有些运营商就可能连接不上，更不用说有时可能遇到整个 IP 段⁸都被墙掉的事。如果网站不巧被黑客盯上，基本上个人也是无力防御 DDoS⁹ 攻击的，随便被攻击一下就会下线。如果博客内容惹到了谁的话，就需要当心了。

上面讨论的是 WordPress+VPS 的主流方案。WordPress 的主要优点是用户群最多，因而可选的主题和各类插件极其丰富，遇到问题也容易找到解答。自己买 VPS 虽然有点小贵，但主要优点是，除了放自己的博客之外，还可以用这个服务器做些别的事情，比如说挂个 BT¹⁰，设个同步网盘¹¹，弄个备用梯子什么的。这套方案的主要缺点一是小贵，二是访问性能不大理想。如果希望提高访问性能的话，装一个 AMP 插件可以让搜索引擎替你缓存页面。

自建博客当然也有其它的方案。
如果不用 VPS⁵ 而用虚拟主机⁶的话，费用可以再降一些。两者的详细对比见脚注。我并不推荐虚拟主机⁶，因为它无法绕开 VPS⁵ 方案的缺点（不能保证任何地方的访客都可以流畅访问），还不像 VPS 一样灵活，在博客之外的可玩性要差一些。这种使用 cPanel¹² 的虚拟主机倒是有一点好，就是对于用户更加友好一些，几乎不用碰命令行，但是也就没法折腾些别的东西玩。还有一种更加简单的服务，只提供一个可以让用户上传文件的 FTP，现在已经没什么人用了。
动态博客除去 WordPress 外，也有不少其它方案可以选择。比如说有的人喜欢 Typecho 的极简。还有人用其它的 CMS 系统如 Joomla! 和 Drupal。不过其它方案的人气都没有 WordPress 这么高，因此不太适合技术能力不足或者不愿意折腾的人。
也有人在自建服务器上放静态博客。在当年最低配 VPS 还普遍内存比较小的时候这还可以节省点服务器资源，现在这么做的优点实在不多。不是说它以前的优点不复存在，而是说现在和使用 GitHub 之类的大型网站部署静态网站的方案相比没有优点。使用 GitHub Pages 可以享受它的免费全球 CDN¹³ 和防御，自建服务器还需要为此伤脑筋。我能想到自建服务器上搞静态博客的唯一理由是博客体积或者访问量太大超出了 GitHub Pages 的限制。如果是这样的话，使用自建静态网站外加 CDN¹³ 会是一个好选择。

Tips

各种 WordPress 建站的教程网上有很多，这里只提一些不太容易被注意到的事情。

VPS 选购时，一般认为 KVM 和 Xen 方案的比 OpenVZ 的好
使用 LNMP 或者 LAMP¹⁴ 一键安装包来准备 WordPress 的运行环境时，推荐使用 VPS 服务商提供的一键安装包而不是网上随便什么地方找的一键脚本。后者有可能会和系统包管理器冲突导致网站在升级后挂掉
- 懒人也可以使用 docker compose 部署 WordPress
要注意常见的 Linux 服务器安全守则：关闭密码登录¹⁵，打开防火墙，做点基本的攻击防护，经常更新系统和软件。不然你就是在裸奔
WordPress 也要经常更新。每年都有不少新的漏洞被发现
不想折腾以上东西又想要 VPS 的性能或者可玩潜力，那么就用托管型 VPS⁷吧
启用 HTTPS 可以增加在 Google 结果中的权重，证书用 certbot 从 Let’s Encrypt 获取就可以了
手机友好的页面在 Google 结果中更靠前。所以不要用太老旧的主题。若是能打开 AMP 尤妙

静态博客

最流行的方案是 GitHub+Jekyll，大概情况如下表

方面	评价
技术门槛	中等
费用	无
访问性能	较好

对技术不了解的读者可能会对「静态博客」是什么感到迷惑。所谓静态，是指博客的页面都是由静态网页构成，不涉及需要服务器动态计算处理的内容。打个比方，类似于大家去食堂吃饭：有的食堂把饭菜预先装盒，你只能拿到成型的盒饭；有的食堂会设有打菜窗口，根据客户需要现场装盒。前者就是静态，网页已经生成好了，访问者看到的就是现成的网页；后者就是动态，根据情况生成需要的网页¹⁶。静态博客可以提供相当好的访问性能，但本身并不能承载用户评论之类的动态内容，往往需要外挂其它服务来实现。

就静态博客来说，现在最流行的是使用 GitHub 搭建静态博客。因为 GitHub 这个网站已经成为当代各行各业（包括体制内）码农的必备生产工具，它已经太大而不能倒，墙掉它是一个会让决策者颇踌躇的事情。另外一点难得的就是 GitHub Pages 是没有广告的，适合价格敏感人群。使用 netlify 和自建 VPS 之类的服务端的讨论见本节最末。

主要的限制是流量和总文件体积。前者是每月 100G，不放图片的话不大容易超，但是被 DDoS⁹ 攻击的话很可能会下线；后者限制为 1GB。因为 GitHub 提供网站的 CDN¹³ 和防御，访问性能也是相当好的。主要的缺点是对于非程序员来说需要一定的折腾精神才能上手，发布文章需要有 git，没法在手机上随手写随手发。种种不便和折腾对于习惯了「注册帐号、访问网站即使用」的用户（特别是广大人文学科培养的朋友）而言可能仍有裹足难行之处。

GitHub Pages 支持普通 HTML，markdown 和 org 文件。只写 markdown 的话页面过于素净，但纯手写 HTML 更是自己找虐。所以主流的选择是使用一款博客网站静态网页生成工具将自己的博文目录转换为一个静态网站并同步到 GitHub 上。目前主流的选择主要有 Jekyll，Hexo 和 Hugo 三款。

Jekyll 有 GitHub 官方背书。不需要先生成 HTML 再上传到 GitHub，站点源码可以直接上传到 GitHub 上，因而写博客的机器上不一定要安装 Ruby Gem 和 Jekyll 程序。但如果使用了一些复杂的主题，则必须安装 Ruby Gem 和 Jekyll 并在本机生成 HTML 后上传发布。
Hexo 使用 Node.js 开发。在本机生成网站的速度比 Jekyll 更快一些，中文文档相当完善。设计上专注于博客，想用它做其它网站比较困难。
Hugo 使用 Golang 开发，生成网站的速度比 Hexo 更快。这些年来发展速度极其迅猛，大有超过前两个的势头。比 Hexo 更加灵活，也可以做博客以外的其它类型网站。

三个方案选哪个呢？如果读者自己会写 Ruby/js/Go 的话，选择自己最熟的语言对应的生成器。如果都不会，去三家的网站上挑一个自己最喜欢的主题就好，对于轻度使用者来说三者并没有那么大的区别。

相对于鼠标点点点就可以搞定的 WordPress，使用这些方案要想开始写博客，至少需要先学习 markdown 的语法，在电脑上安装 Ruby/Node.js（安装 Go 不是 Hugo 必须的），安装生成器，学习使用 git，然后才能开写，适合程序员或有折腾精神的人。值得指出的是，对于没有技术背景的人来说，git 并不是一个容易学习的软件，GitHub 的 Windows 客户端也不是一个好用的客户端。虽然说不懂技术的人也可以用 GitHub Windows 客户端用鼠标点点点来完成基本的代码同步，但遇到问题的时候并不容易排查。尽管网上有相当详尽的博客部署教程，但这些教程在用户走到岔道的时候不一定能管用¹⁷。

这三种方案的准备工作都差不多。安装网站生成器本身，fork 一个喜欢的主题，再建立一个目录存放自定义的网站数据和博文。建立自己 GitHub Pages 的 repo 并使主题的输出目录指向它（或者使用 git submodule）。每次发布需要使用生成器生成网站，然后再 push 上去。

如果读者有一些钻研精神，不满足于上述中文互联网上常见的标准建站教程指示的工作流程的话，GitHub 于 2019 年推出的 GitHub Actions 可以进一步简化上述工作。本地甚至不再需要安装站点网页生成器（以前是只有简单的 Jekyll 站不用安装，Hexo 和 Hugo 都必须自己生成网页），专心写博客，写完文章 push 上去之后 GitHub 可以替你完成后续的工作。

这也算是抹平了 GitHub Pages 和 netlify 的一个重要功能差距。netlify 一直就可以自动替你完成网页生成的步骤，操作比 GitHub Pages 要简单一些。其免费版也提供每月 100GB 流量而并不限制站点数目，流量超出之后可以付费购买更多流量，而 GitHub Pages 是一个纯粹的福利项目不能付费升级。netlify 同样提供全球 CDN¹³ 加速。这两年 netlify 人气上升得很快，是值得考虑的一个选择。目前大概因为它的企业用户众多且它还没有多少国内个人用户，此站还没有被墙。

也有一个方案是使用 Google Apps Engine 来实现和 netlify 一样的自动构建和托管。但是由于墙的缘故，必须自己配置一下第三方 CDN 才能让大陆访问。设置也要麻烦一些。

自建 VPS 当然也可以用上述 Jekyll/Hexo/Hugo 来部署静态博客。不过如前面所讨论的，相对于专业服务商来说，这样做并没有什么优点，仅供流量需求特别大的人使用。

Tips

多台电脑同步既可以使用 git，也可以使用网盘
Windows 下安装上述博客生成程序，可以试试 scoop
不推荐从源代码开始编译 Hugo，因为会下载 2GB 之多的库文件。直接用编译好的 Hugo 就可以
学会使用 GitHub Actions 或者使用 netlify 之后就不需要在自己电脑上装博客生成程序了，同步和写作都会更方便一些
上述生成器的大部分博客主题都已经带了 RSS。如果生成的主页上没有找到 RSS 的话，可以试试网站地址/feed.xml 下是否有 RSS。有的话手工添加一个超链接即可。
虽然网上大部分教程都推荐使用图床，但如果博客访问量不会超过 GitHub 限制的话，图床并不必要。懒得折腾就算了
即使流量超限，除图床外还有一个选择就是使用全站 CDN。CloudFlare 的免费服务可以顶一顶看

大型博客托管商

虽然说国内没什么有节操的博客托管商，但是境外还是有一些的。最有名的是 Blogger 和 WordPress.com。这两家都提供自定义域名和完整的用户数据导入导出。Blogger 和 Blogspot 是一个东西，前者用于写博，后者是博客发表所用的默认域名。

使用大型博客托管商的最大好处是不需要操心任何技术细节，他们提供强有力的团队进行运维，自己的博客几乎永远不会因攻击而下线，在全球除中国大陆以外的地区访问速度都很好。主要的缺点则是在大陆访问往往有窒碍之处。即使有时可以通过换绑自己的域名以绕开限制¹⁸，但并不能保证大陆用户的普遍可达，且这些方法何时失效也是不确定的事情。

就 Blogger/Blogspot 和 WordPress.com 两相对比的话，前者完全免费，而后者提供更多的自定义功能。就可选的主题¹⁹来说，Blogger 要少一些，大部分主题都比较难看。值得一提的是，Blogger/Blogspot 并不提供自定义博文链接的选项，URL 只能使用固定格式，所以不是完全意义上的自主博客。而 WordPress.com 的免费版功能相当受限，页面还有广告。想要发挥 WordPress 博客的诸多强大功能，需要付费订阅²⁰。尤其是如果有安装插件的需求（使用插件增强博客的功能对于自主建站的人是很常见的）需要选择每月 25 美元的 Business 版。故而若有特定需求的话不比自行建站便宜。

这里再多说一下 WordPress 套餐（Plan）的选择。如果只是想有个地方写字，对于一切除简单主题¹⁹以外的定制都兴趣不大的人，免费服务不失为一个选择。但是 WordPress.com 免费服务不能绑定自己的域名，不属于这里我们推荐的「自主博客」。Blogger 相较之下是更好的选择。而要想绑定域名，WordPress 最便宜的套餐年付 48 美元，与自行建站的费用相差无几，胜在省心省力不用操作运维。想去除广告至少需要年付 96 美元，大部分人会觉得不值。年付 300 美元的 Business Plan，老实说，只适合真的想用网站赚钱的人。如果只是为了使用一两个插件，这个代价未免太高。

综合来说，如果不在乎境内访客的话，免费服务选 Blogger 更好一些；愿意花钱的话就需要在 WordPress.com 的套餐和自己建站之间犹豫一下了。

Medium 等较年轻的平台因为截止本文写作时并不提供绑定自定义域名的功能，故而不推荐。

Matters 是一个很好的平台，但并不是一个传统意义上的博客平台，也不提供绑定域名的功能，在此不做讨论。

小型博客托管商

相对于大型博客托管商的尽数被墙，小众博客托管商在有着大型博客托管商的运维优点的同时，有可能尚未被墙。如果没有被墙且符合前述自主博客的定义，那么也是很好的选择。如果是像 Bitcron 这样的邀请制注册，可能相当长时间内都不会有问题。

我个人很喜欢 Bitcron 的愿景：作者只需要用 markdown 专注写作，其它都交给 Bitcron。几乎没有缺点：写作方便，文章数据透明，访问性能好，用户不需要折腾容易上手。没有免费版但价格也可以算非常公道。

对于这种小型服务商就不要苛求它们提供免费服务了，它们也没有巨型企业在后面支持，不收费难以维持优质的服务。

更新：Bitcron 作者可能在计划新的东西。也许会有更新更好用的产品出来
更新：netlify 因为现在还没引起国内的普遍注意，也可以算是小众服务商。讨论见静态博客部分。它的免费版相当够用，使用有一定门槛。并不算零门槛服务，不大能算作此类。

选哪个？

上手难度

专业博客托管商最容易上手。其次是自建 WordPress。GitHub Pages 需要有一定的折腾精神

费用比较

GitHub 和 Blogger 最便宜，其次是一些小型博客服务商。WordPress.com 和自有 VPS 都要贵一些

访问性能

境外访问的话，GitHub 和 Blogspot、WordPress.com 没有显著差别。大陆访问的话，对大陆有专门优化的小型博客服务商有显著优势，其次是 GitHub。自建服务器不大稳定，而大型博客服务商被墙得很厉害。

写博手段

写博方式	支持情况
在线写博	除静态博客外基本都支持
邮件写博	除静态博客外基本都支持
微信写博	个别小型博客商支持
markdown	基本都支持，可能需要插件或者第三方服务
GitHub	GitHub 静态博客；WordPress 可以装插件

可见就「随时随地写作」来说，GitHub 静态博客方案是最不方便的，其它几种都相差不远。

如果读者像我一样希望所有的博文数据都有 markdown 导入导出支持的话（这样清晰易读容易导入导出，文档结构和样式分离，方便搬家跑路和一文多发。此外，所有博文在硬盘上看得见摸得着会让强迫症感到非常舒服），GitHub + Jekyll/Hexo/Hugo 当然是原生支持。如果使用 WordPress 的话，中文博客可以安装Writing on GitHub插件。有一个人气更高的插件 wordpress-github-sync 但是据说对于中文博客标题会有 bug。Bitcron 平台原生支持 DropBox 同步和 markdown 写博。

长期可持续性

不得不承认的一点，大部分人心血来潮开了博客之后坚持不了几年就因为工作繁忙或者结婚生娃而再也不写了。决定能否长期写下去的主要因素是上面的「上手难度」和「写博手段」两点。像 GitHub 静态博客方案，对于没有技术背景的人，如果半年没写，多半就忘记怎么发博了。在考虑开博的技术方案时，对于自己未来做事的恒心也要有充分估计。

假如在最坏情况下，真的彻底封笔不写或者懒得维护下去的话，另外一个值得考虑的因素就是自己已经写下的文字是否能长期存在。目前看来，GitHub Pages 和 WordPress.com 本身都可以保证长期存在下去，至少未来十年不会关闭。但值得指出的是，长期不用的账号有可能被关闭和回收。下面分别讨论几种不同的服务端方案：

GitHub Pages：只要自己还在持续使用 GitHub 就不用担心被关闭。但如果除了博客以外从来不用 GitHub，那就有可能被回收帐号。目前没有明确的账号长时间不用的回收标准。此网站会长期存在。
WordPress.com：目前没有明确的免费账号长时间不用的回收标准，但我认为帐号被回收的可能性较小，因为 WordPress.com 可以从页面广告回收成本。此网站会长期存在，付费用户只要一直交钱就可以保证网站存在。
Blogger：Google 帐户只要还在使用就不用担心 Blogger 被关。但 Google 有砍掉产品的恶劣先例。目前没有证据证明 Google 有关停这个服务的想法。
netlify：作为一家初创公司，虽然目前势头极好，在未来十年是否会被竞争对手挤掉尚不确定。
各种小型服务商：不大确定，全看创建者是否靠谱是否愿意一直维护。
自建 VPS：只要一直续费就不会有事。但总不打理的话，网站有一定概率挂掉。还需要注意域名也需要一直续费。

社区资源

WordPress 拥有最多的社区资源，最丰富的主题和插件。即使要跑路，几乎所有其它方案都能找到从 WordPress 导入的工具。其它几种选择的社区资源要差一些。小众博客平台的主题选择是最少的。

安全防御

如果因为博文得罪了人而被 DDoS⁹ 攻击的话，自建服务器几乎完全无力应对攻击。GitHub Pages 也可能下线，因为这不是 GitHub 的核心业务，犯不着花大力气帮你防护。小型博客托管商的防护能力每家都不一样。防护能力最强的是 Google Blogspot，而 WordPress.com 也不错。

除去旨在使网站下线的 DDoS⁹ 外，自建服务器还要当心各种以控制服务器为目的的常规攻击。去后台看一下的话，每天几千次试密码是稀松平常的事情。不做基本防护而成为肉鸡²¹或者被挂马²²的个人网站很多很多。

广告收入

对于本文所列举的各种开博客方法，大部分只需要自己有域名就可以放广告。Google AdSense 之类的广告方案要求拥有根域名，这也是自有域名的一个重要好处。如果自己没有域名而需要使用博客托管商的域名的话，Blogspot 因为是 Google 自家的，可以直接开通 AdSense。而其它平台往往需要付费才能控制自己页面上的广告。值得一提的是，WordPress.com 即使是付了钱，绑定了自己的域名，似乎也只能使用它自家的 WordAds 平台来放广告。

当然，这年头没多少人读博客，想靠广告来回本甚至赚钱基本是不可能的。急功近利反而容易失了开博的初心。所以广告收入这一项也就是列在这里供参考而已。

总结

下表对于有代表性的自主博客方案做了一个汇总。不大推荐的方案没有列入，详见前述章节的讨论。

	WordPress+VPS	GitHub+Jekyll/Hexo/Hugo	WordPress.com	Blogger²³	Bitcron	静态博客+VPS+CDN
搭建难度	较低	中等	很低	很低	很低	中等偏难
易用性	好	中等	好	好	非常好	中等
写博手段	多	单一	多	多	非常多	单一
社区资源	非常多	比较多	非常多	多	少	一般
最低费用	60 美元/年	0	48 美元/年	0	60RMB/年	60 美元/年
长期可用	要一直交钱	只要帐号存在	同左	同左	几年	要一直交钱
访问速度	一般或较差	较好	境外好境内差	同左	较好	较好
流量限制	1TB/月起	100GB/月，不可加购	无	无	3GB	10TB 级起
并发承载²⁴	差	很好	好	好	好	很好
文件限制	20GB 起	1GB	6GB	15GB 起	1GB 起	20GB 起
安全防御	差	较好	好	很好	一般	一般
广告收入	可自设	可自设	付费，WordAds	AdSense	可自设	可自设

综上，如果你的主要读者都在境外，选 Blogger/WordPress.com。不想掏钱就用 Blogger。否则用 WordPress.com。想折腾的话也可以用别的方案。

如果你的主要读者在大陆，那么就需要平衡一下费用、折腾程度等因素了。不想出钱但是不怕折腾的话选 GitHub/netlify 静态博客。愿意出点钱以免折腾可以选择靠谱的小型博客服务商如 Bitcron。喜欢完全自主掌控感的，选自建服务器（也就是说既费钱又有点折腾）。

系列文章

为自己，为别人，准备一条路
 预防封号：备用联系方式的选择
 告别删文：在哪里写博客？

原文使用「独立博客」一词，但因为中文语境中对此词语已有约定俗成的定义：自己拥有域名和服务器的博客，故在此另造新词「自主博客」以免误导读者。按，英文世界中向无「独立博客」的说法，独立博客也不如中文世界中这样流行。这有几方面原因，一方面是独立博客不过是自有服务器的个人网站的一种特殊形式，有能力建站的人并无必要特别吹嘘自己「独立」建立了一个博客。另一方面，由本文讨论可见，自行建站在性能上缺点颇多，英文世界的内容审查不似简体中文世界这样严格，大部分人可以信任博客托管商，最多只有绑定自己域名的需求，并无自建服务器的需求。私以为中文世界中的「独立博客」之义用「自有博客」更名实相符，大家都称之为「独立博客」暗含有对国内诸博客运营商的不满之意。 ↩
URL，Uniform Resource Locator。访问一个网页时在浏览器地址栏所显示的网页地址即是该网页的 URL。网页的访问者只关心 URL 而不关心网页具体放在哪里。故而可以将一个 URL 指向新的地方 ↩
域名，domain name。例如 www.google.com 就是一个域名。对于一个形如 https://blog.wangxuan.name/2020/03/04/where-to-host-my-blog/ 这样的 URL，其中 blog.wangxuan.name 就是域名。如果不拥有一个 URL 中的域名，那么就无法将该 URL 指向一个新的 IP 址，也就无法自由迁移自己的博文到新的地方。 ↩
仍以本文为例，https://blog.wangxuan.name/2020/03/04/where-to-host-my-blog/ 就是本文的静态链接。有的博客喜欢使用像本文一样的日期加标题的形式，有的喜欢使用博文 ID 的形式，有的喜欢使用仅含标题的形式。如果迁入的新博客平台并不允许将博文的静态链接设置成自己想要的样式，那么便可能无法重现原来博文的 URL。 ↩
VPS，Virtual private server，虚拟专用服务器。所谓虚拟，是指用户并不真的拥有一台物理服务器，而是将一台实际的物理服务器出租给一个或多个（一般是多个）用户使用。但对于用户来说，使用感受与一台真实的物理服务器无异，所以称之为「虚拟专用」服务器。什么是物理服务器？就是一台看得见摸得着的计算机。打个比方说，如果一台接入互联网的物理服务器相当于临街的一座楼，那么 VPS 就是这个楼的临街一面有不止一个门牌号（IP 地址），你买下了其中一个有自己门牌号的门脸用来做生意，店铺里一切由你做主，水电也都是独立的。从店主的角度来说，是否拥有这座楼，对于开店本身并没有什么差异。 ↩ ↩ ↩
当然，虚拟主机这个词也是一个中国特色的词语，并不是一个严谨的技术词汇。和前面的 VPS 的主要区别是，用户并不能获得相当于拥有一台物理服务器的使用体验。往往多人共用一个 IP 地址不说，超售而影响服务性能也是比较常见的事情。还用前面的比方，你获得的只是大楼中某个房间的「收信地址」用来做电商。但这个房间还挤着别人，你只有这个房间的一个隔断的使用权。有人给你寄信之后，大楼物业负责分拣信件给你。如果你邻居的信件特别多，也许给你的信件就会漏送。更糟糕的是，万一有邻居用了大功率电器而跳闸，你也要跟着一起倒霉。不过虚拟主机也并非全无可取，既然物业代理了信件收发和水电暖维修，如果物业服务很好，房间宽敞，用起来也可以舒心省事。 ↩ ↩ ↩
托管型 VPS，就是你买了 VPS，但是运维工作由别人（比如说某个非常好用的工具）代理。对于不想折腾，不想碰命令行的人，这是一个好选择。当然，给你维护网站的工具是要收钱的。详细介绍见这里 ↩ ↩
IP 地址是一台计算机在互联网上的地址。自然一个 VPS 商的 IP 地址是连成一片的。封禁 IP 段相当于封掉整条街，自然上面的商户全都倒霉。 ↩
DDoS, Distributed Denial-of-service attack，分布式拒绝服务攻击。简单地说，就是发起大量的访问，使服务器无力承载而下线。对于 VPS 用户来说，比较常见的情况是被攻击后流量超出服务商的限制而被服务商下线。 ↩ ↩ ↩ ↩
挂 BT 是使用 P2P 类下载软件下载东西的俗称。BT 一词源于最早的 P2P 下载协议 BitTorrent。现在一般说挂 BT 的话，也可以指其它协议如 eMule 所用的 ed2k 协议。使用服务器挂 BT 的话，自家的电脑就不必一直开机。 ↩
自建同步网盘的需求主要是大陆用户。因为大陆 ISP 一般不为家庭用户提供公网 IP，且会封禁常用服务端口，难以用家用电脑架设网盘。 ↩
cPanel 是一种常见的虚拟主机管理界面。在上面可以方便地一键部署 WordPress，上传文件什么的。 ↩
CDN, Content Delivery Network，内容分发网络。打个比方说，你的仓库在北京，广州的顾客收货就会慢。CDN 的作用就是在全球各地建仓库，使得任何地方的顾客都可以从最近的仓库收货。因此 CDN 服务商会复制一份你服务器上的内容，并根据访客的位置来决定从哪个服务器提供内容。 ↩ ↩ ↩ ↩
LNMP: Linux, Nginx, MySQL, php。LAMP：Linux，Apache，MySQL，php。两个都是常见的 WordPress 运行环境 ↩
也就是只允许 SSH pubkey 登录。这样可以降低密码被试出的风险。如果觉得不方便的话，至少要禁止 root 用户远程登录。也可以安装 fail2ban 以减少密码被试出的机会。 ↩
感谢 atreides 贡献这个比喻 ↩
对于没经验的用户来说，自己排查故障是如此费时间，以至于一般情况下，按教程从头重来一遍可能更省时间一点。 ↩
这种操作方法的原理是：虽然 Blogspot 和 WordPress.com 的域名解析在大陆是不能用的，但我们可以用自己的域名绕过此限制，将自己的域名指向一个目前尚未列入封禁列表的 IP 地址。由于博客已经不再是目前封锁的重点，防火墙的 IP 黑名单更新不一定及时，故而此法有相当的可行性。但此法在形势有变时随时有可能失效。 ↩
对于博客来说，主题可以理解为是整个网站的外观风格的一揽子解决方案。安装对应主题之后，可以在不改变博文内容的情况下整个改变站点的面貌。一些特别复杂的主题甚至可以实现电商平台之类的复杂功能。 ↩ ↩
绝大部分服务都需要按月或按年付费，不能一次付清买断 ↩
肉鸡，指被黑客控制的计算机。黑客可以操作被控制的计算机做各种不可告人的事情，比如说用来发动对其它网站的攻击 ↩
挂马，被挂上木马。指网站被篡改后被用于分发恶意程序，使得访问者的计算机可能受到感染 ↩
如前所述，Blogger 的博文链接不能自定义，只能接受。此举不利于迁入它，但从它迁出还是可以的。故而也算作「准」自主博客列入本表 ↩
同时可以有多少个用户访问网站 ↩

预防封号：备用联系方式的选择

Update on Aug 06 2020: 写此文时正值大批朋友微信号被封而失联，谈的还主要是删号的应对。那时也没有想到有一天我们会讨论「微信还能不能用下去」的问题。想看微信等价物推荐的朋友，可跳过「注册马甲」一节，甚至直接跳到「聊天软件」一节也无不可。

Updated on Aug 01 2020: 添加了 keybase 被 Zoom 收购的新闻，未撤回对 keybase 的推荐。

继续昨天的话题，今天开始掰开细讲讲昨天说的各方面。先讲最重要的好了：如何应对杀档？

及时备份资料

这条说起来容易做起来难。因为大部分人并不懂技术。虽然现在 GitHub 上几乎什么网站的备份代码都可以找得到，可是对于没有技术的同学还是未免太难。所以，平时没事结交两个技术宅朋友吧！

但选择一些备用的联系方式，则并不需要懂什么技术。在登不上原帐号的时候，使用备份联系方式和朋友保持联络，也是相当靠谱的。他们有种就把全站用户都杀掉嘛！我们换个地方，接着聊！

备用联系方式的选择

注册马甲

如果能够预知自己发的某些内容会有风险的话，提前养一个小号是一个好主意。可以让自己的马甲专门用于发危险内容，这样主号被封的概率就要小得多，也就不用头大资料备份的事情。大不了马甲被封掉之后再注册一个就是。

注册马甲的注意事项：

不要使用和主号同样的手机号、邮箱进行注册。否则会一封全封。
如果有条件使用境外手机号注册，优先使用境外手机号注册。由于种种原因，目前来看，境外手机号注册的微信号被封之后大概率仍然可以正常使用，只是发出的东西大陆手机号注册的朋友看不见。而大陆手机号注册的帐号被封之后是完全无法使用的。当然，境外手机号注册的帐号影响力大到一定程度也会被彻底杀档，只是绝大部分人够不到那条线。不是所有平台都像微信一样中外有别，但一般来说用境外手机号除了功能受点限制，总体是利大于弊的。
- 有很多买到外国手机号的方法，其中不乏免费服务。如果信不过那些小公司的话，可以购买一个 Skype 外国号码，就是略伤荷包。直接在淘宝买一个支持漫游到中国的外国 SIM 卡也是可以的。这些破财的办法供不会科学上网的朋友使用。
- 比较经典的一个套路是先去小网站注册一个免费的美国号码，再用它注册 Google Voice，最后用 Google Voice 号码注册微信。平时注意时不时登录一下自己的 Google Voice 帐户，免得号码被 Google 收回，被收回的话自己的微信号也就不安全了。
- 境外手机号注册的微信使用微信支付不方便。在网上可以搜到破除限制的方法，但是绑定银行卡之后也就把自己的主号小号连了在一起一损俱损，还是放弃吧。
完全没有任何使用记录的小号被封杀的可能性要高于长期使用的微信号。所以，有事没事养一养号，发发消息，点点赞，关注个公众号什么的。

注册完之后及时添加自己朋友。最好是在聊天中亲自发送名片，以防别人冒充自己。也可以在朋友圈中发送小号的二维码。这样做会损失一点匿名性，需要匿名的朋友就不要用了。

当然，这并不是根本性的解决办法，只是对封号后的损失做了一个隔离。我更推荐更彻底的方案：一劳永逸地结束这种躲迷藏，请往下看。

境外社交网站

之所以把这个放在前面来说，是因为想把自己朋友圈整个搬过去以继续原来的讨论的话，这是比较容易的。恐怕很多未雨绸缪的朋友已经注册了那些著名的「不存在」的网站，比如说 Facebook 什么的。

个人来说我对 Facebook 毫无好感。Facebook 和微信一样，都是自由互联网的敌人。但毕竟它们用户最多，注册起来最方便，大部分人还是用它们最省力。不过 Facebook 之流，也不是那么自由。当然，上这些不存在的网站需要科学上网技术，所以也不是真的毫无门槛。

如果，我要选择自由呢？

要自由，就需要付出点代价。使用体验不免打些折扣，另外能一起玩的人也会少一些。

如果要微博类似体验，要不要试试 Mastodon？和 Twitter 不一样，它是开源、开放的。任何人都可以搭建自己的服务器，没有人可以掌控整个网络。

如果你是技术宅的话，自建论坛是一个好主意。咳咳，在大陆的话，论坛的备案手续极其繁琐，服务器还是放在外面吧。另外，互联网上古的社交工具，如 IRC、Usenet、BBS 现在还没有死绝呢，有兴趣和同样的技术宅一起玩的话，也是不错的。

既想要朋友们一起玩，又不想费劲学技术，有没有什么办法呢？最好连墙都不用翻。有没有这样的给小白的完美方案呢？其实是有的。邮件组就可以满足这个需求。虽然勤看邮箱的人可能很少了，但电子邮件地址是一定每个人都有的。

雅虎倒闭之后，现在最好用的邮件组大概是 Google Groups 了。可惜需要至少一个管理员能够科学上网才能使用。
退而求其次的话，国内许多邮箱的企业邮箱也是提供邮件组功能的。愿意花钱的话也是一个选择。
最后，如果实在上面的都不想用，设置一个公共邮箱，并设置好自动转发规则，也可以将就。只是每添加一个成员，就得修改一次邮件规则，颇不方便

我只在乎最重要的朋友！

既然说到电子邮件了，那么就好好谈谈各种更侧重于沟通而不是社交的工具吧。

电子邮件

可靠的邮箱服务商有很多，这里只谈最流行的几个推荐。GMail 虽好但在墙外。微软的 Outlook 邮箱不需要科学上网，也相当够用。国内邮箱服务腾讯最好，网易这两年还凑合但我并不认为它的信誉已经恢复，个人不推荐它。其它新浪搜狐百度阿里之流，如果不想自己邮箱里的东西泄露得哪都是的话，千万别用。

推荐使用国外邮箱服务商。也就是说不打算花太多精力挑选的话，会科学上网用 GMail，不会科学上网用 Outlook，是不大会出错的选择。防火墙不仅会拦截梯子和网站，也会检查电子邮件！如果电子邮件加密或者含有不和谐内容，可能在穿越边境时被丢弃！因而使用国内邮箱时可能会收不到国际信件。如果确定所有通信的人都用的国内邮箱，那么 QQ 邮箱也可以使用。
有精力的话可以熟悉一下 PGP 和 S/MIME 邮件加密。但这两个东西配置起来并不省事，获得的收益也不大。主要是防止邮箱服务商偷窥信件内容。并不能用它们穿墙，因为此类信件在穿墙时有很大概率会被丢弃。

聊天软件

很遗憾的是，绝大部分境外聊天软件都面临着一个命运：如果用户很多，就会被墙。它们既不能像社交网络服务一样快速传播信息，用户也不多，还不一定好用（考虑到需要科学上网），所以我把聊天软件放在最后来讨论。

最火的两个境外聊天软件 Facebook Messenger 和 Whatsapp 都是 Facebook 的。后者目前宣称使用加密，Facebook 无法窥视信息，但大家普遍对于 Facebook 的节操比较不放心。如果愿意用 Facebook 的话，倒也不在乎这点了。如果讨厌 Facebook，可以往下看。

Telegram 可能是最近人气涨得最快的聊天软件，在上面有很大概率可以找到自己的朋友。功能丰富，聊天使用体验比微信更好，也支持群聊和 channel （类似于公众号）。但它的缺点也是不容忽视的：不开源，默认不加密传输，加密聊天时无法解决 TOFU (Trust on first use) 问题，严重依赖手机认证。当然，这些缺点并不影响一般聊天。只是当有人大吹法螺说它多么安全的时候，心里知道并不是那么回事就是了。微信更不安全，但大家还是天天用不是？

对于更注重安全的人来说，Signal 是一个流行的选择。开源，默认加密。由于协议混淆做的好，大概率可以在墙内使用，这是很大一个优点。当然，它功能比 Telegram 少一些，同样严重依赖手机号码，所以并不完美。

我个人的最爱是 keybase。既像 Telegram 一样功能丰富（比 TG 少了一些功能，但多出的功能更多），又像 Signal 一样安全（其实它比 Signal 更安全，不再需要手机号，也很好地解决了 TOFU 问题）。主要的缺点是目前用户太少，另外手机配置太差的话群聊会卡。因为用户太少，现在还没有被防火墙盯上。（keybase 现在已经被 Zoom 收购。不过 keybase 的加密算法是公开的，其快照 hash 也在比特币上定期公布，无论是加密安全性还是身份认证的可靠性都与运营者无关，目前不受收购影响。）

如何公告自己的备用联系方式

好吧，说了这么多，自己被封号的时候朋友联系不上，有嘛用啊！

可见一个写满自己联系方式的个人网页有多么重要。应该在自己所有的网络平台的个人介绍页放上自己个人网页的链接，并说服自己的朋友们也这么做。

个人网页不一定要自己架站，写在 github 之类的地方都可以。哪怕使用国内博客服务也行，只要不作死把那个帐号也搞没就是了。

最坏的情况是自己帐号消失得十分彻底，朋友们都没来得及存联系方式。因此这个个人网页最好可以被搜索引擎轻松搜索到。如果同名者太多，主页上应尽可能加上学校公司等方便定位的个人简历信息。

（鄙人的联系方式都在鄙人主页上。将本博客域名的 blog 替换为 www 即可查看我的主页）

如果我要匿名呢？

前面讨论的都是一般性的需求。如果出于某些原因，要求完全不可追踪到自己，还需要额外注意一些问题。

不要使用 Outlook 邮箱。微软不一定不会交出你的资料。GMail 只能满足最低要求。自建邮箱或者其它口碑较好的注重隐私的邮箱可能会更好。
如果你的常用帐号/昵称已经在任何一个实名制服务上使用过的话，当寻求匿名的时候切切不可再次使用相似的帐号/昵称。电子邮箱同理
不要使用实名制服务，除非你有把握骗过实名制验证
不要使用常用手机号注册服务。用于注册服务的手机号应确保不会被追踪到自己
如果你的手机或者电脑自带了同步备份功能，需要留心。不确定是否有身份信息和通讯信息同时被上传的话，最好关掉同步备份功能。
使用 Telegram 时，一定要打开两步验证。推荐使用加密聊天。Telegram 和 Signal 的注册手机号都需要注意。keybase 不要链接到自己的常用帐号
推荐使用邮件加密
可以考虑使用 CryptoCat 等更注重匿名的沟通工具

如果更进一步的话，还可以考虑

使用 TOR 或值得信赖的 VPN 服务商隐藏自己的真实 IP
慎重选择自己的好友，如果好友圈和大号一样，很容易被鉴定身份。慎重告知在线朋友自己的真实身份

系列文章

为自己，为别人，准备一条路
 预防封号：备用联系方式的选择
 告别删文：在哪里写博客？

为自己，为别人，准备一条路

本文会不定期更新，以反映当前推荐。最近更新：2020 年 3 月 7 日

我很想给这篇文章起一个更符合它本意的标题，却因为担心被过滤而放弃。写这篇文章的时候，也在绞尽脑汁绕开各种形形色色的不可说的词汇——这个列表现在是越来越长了。这种荒诞一个月来每个人都感同身受。任何一篇看上去有意思的文章，都要抓紧时间看，因为下次点开的时候很可能只能看见一个红底感叹号。

无庸讳言，这次国难的严重后果与信息的封锁不无关系。我们见证了传统媒体在这次事件中的集体失声——老实说，这并不令人奇怪，由于种种原因，他们本来就在缓慢走向死亡。自媒体业已成为大众获取最新信息的首要通道——而我们却见证了新的中国速度：文章被撤的速度。我想，这或许应该成为一个无关政见的共识：保证每一个真实的声音都可以被听到，对于避免这样的灾难至关重要。

互联网刚流行的时候，人们说：在网上没有人知道你是一条狗。现在我们可以说：你永远不知道那头看你的文章不爽要拿掉的是不是一条狗。如今形势有如「南蛮入侵」，反贼要挨一刀，忠臣也要挨一刀，会不会掉血，全凭运气。无论是否拥护建制，都应该承认，为了自己，也为了所有人，我们需要一条通畅交换信息的道路。

然而，尽管「南蛮入侵」已经无法让任何人视而不见，我见到的绝大多数人却仍然只依靠两微一条获取信息。甚至于极其重要的信息，如警讯或者呼救，也都以两微截图的方式进行流传。在中国，移动互联网极其彻底地改变了所有人的信息获取方式。而以两微一条为代表的中心化互联网服务，正是信息封锁的重灾区。讽刺的是，正是在这样的平台上，以截图形式流传的信息反而成为了谣言的温床。

很多人又一次喊出「逃离 XX」的口号，而私以为大部分人并不能做到。社交网络服务天然具有集聚性，我们总是使用我们的朋友所使用的服务。切换到新的平台不仅需要克服自身的懒惰，还需要说服自己的朋友，这太难了。

然而，我们总还是可以做点什么。从今天开始，为自己准备一些 Plan B，让自己再次被迫噤声的时候可以发出自己的声音，让敲钟人敲响的钟声可以被更多人听到，这些并不那么困难。虽然还是需要少许时间来注册一些服务——自由永远是有代价的。

谨在此呼吁每一个为今天的局面感到愤怒的人花一点时间做做下面的事情。当自己辛辛苦苦写了几小时的文章被删掉的时候，当自己看到很好的文章却转眼消失的时候，当自己遍寻真相而不得的时候，花一点时间去行动。每个人都这样做的话，情况就会不一样。

不必一次做到最好，挑选每一项中自己自己最容易做到的立刻去做，并不花费多少时间。世界就是在一点一分的努力中变好的。

一、保证自己有至少一个科学上网的梯子，这是下面几乎所有措施的前提
二、保证有至少一个备用联系方式，以防自己被删号后联系不到朋友：
Facebook、Twitter、Whatsapp、Telegram、Signal、Keybase、IRC 甚至电子邮件都可以
电子邮件推荐使用大陆以外的服务商。有精力的话可以熟悉一下 PGP 或者 S/MIME 邮件加密。
就人气来说前三个用的人更多一些，但大公司并不那么值得信任。
如果注重安全和保密，推荐 Signal 和 Keybase，尤其推荐后者。
Telegram 的功能较多，用户群体现在也不少，安全性凑合，是个比较中庸的选择。
三、保证有至少一个备用的公开信息发布渠道
独立博客、Matters、GitHub、Facebook、Twitter 都可以
- 我把独立博客¹放在首位，因为自己控制一切才能保证不会被删除。这里我所说的独立，是指自己拥有域名，拥有完全的掌握权。为此可以选择自建服务器，也可以使用 GitHub 搭建博客。无论使用 WordPress 还是 GitHub，相应教程网上都有很多
  如果觉得独立博客搭起来太麻烦，也可以使用博客托管商，但不要使用任何大陆博客托管商——覆巢之下安有完卵
  境外著名博客托管商基本都墙掉了，所以也不大推荐。目前 wordpress.com 的 IP 疑似已经解封但何时再次封禁尚不确定。
  同样，不要使用任何国内域名注册商的域名注册服务
  服务器在境外的小型博客托管商如 Bitcron 等因为流量较小大概一段时间内不会被墙，也可以考虑
- GitHub 被墙的可能性暂时是比较小的，不架网站而只使用普通的 md 页面展示甚至于用 issue、gist 来发布信息也是不少人的选择
- 其它三个选择现在都已经被墙，国内的朋友比较难读到。其中 Matters 拥有号称永不删除的特性，如果对「文章永不磨灭」有强迫症的话可以考虑
四、保留至少一个备用信息接受渠道
熟练使用 Google 搜索信息
使用一个 RSS 阅读器订阅自己喜欢的博客
虽然传统严肃媒体正在死亡，但还是应该选择几个自己信得过的传统媒体，记住他们的名字和网站。或者使用新闻聚合服务进行订阅
维护自己的境外社交网络帐号以应不时之需

如果读者不仅有对抗 censorship 的需求，还有匿名的需求（谁也不想去讲「不能！不明白！」是吧），那么在发布和传播这些有匿名需求的信息时还需要注意以下事项

不要使用任何实名制服务
包括所有大陆互联网服务
隔离常用帐号和备用帐号，使人不能发现关联
学习和使用加密技术

这篇文章旨在呼吁大家立刻从可以做到的事情开始行动，故不作深入讨论。对于互联网时代的个人安全防护，将另文详细讨论。

系列文章

为自己，为别人，准备一条路
 预防封号：备用联系方式的选择
 告别删文：在哪里写博客？

为避免与通常说的独立博客的定义相混淆，我在后续文章中将此概念名之为自主博客 ↩

GPG SKS 同步网络被投毒事件及其影响

2019年6月，有不知名攻击者对 GPG SKS 密钥同步服务器投毒，详情见 SKS 网络和 GPG 的核心维护者 rjhansen的解释。根据 rjhansen 的说法，投毒已成既成事实，该隐患短期内无法从SKS或OpenPGP协议中移除。

可能产生的严重后果有许多，比如说，如果有人再次对各大 Linux 发行版包管理器的 GPG 证书投毒，将导致受影响的 Linux 系统无法执行任何包更新。

因为关于这个重大事件的中文资料几乎没有，特此综合英文资料做一综合评述。

熟悉 GPG 的朋友从 rjhansen 文中已经可以明白前因后果。在开始讨论之前，先对不熟悉此事件的读者做一下科普。

什么是 GPG？为什么 GPG 证书服务器被破坏影响很大？
GPG 是 GNU 开源版本的 PGP，是一个加密软件。可以用于加密、签署和验证身份。在开源软件世界中广为采用，尤其是 GNU 生态圈内的各大 Linux 发行版和软件的包管理器都广泛使用 GPG 对重要文件进行签名，以防用户下载到冒名恶意软件。

因此，如果 GPG 不能正常工作，不能正常从其证书服务器拉取证书，可能导致一系列依赖 GPG 的软件出现故障，比如说无法正常升级软件包。
什么是 SKS 公钥服务器同步网络？

GPG 与 SSL 证书系统不同，它不依赖一个权威的第三方来为每一个证书提供背书。相反，每个用户应该自行选择信任哪些证书。那么，如何解决无法见面验证时的 TOFU (trust on first use) 问题呢？这通过所谓的信任网络（Web of Trust）实现。

譬如，我和张三见过面并检查过他的公钥，因而知道张三的公钥的的确确属于他本人，我选择信任张三。而张三同样审慎地验证了李四的证书并为李四的证书签名背书——张三的证书的持有人在此证明该证书是真实属于李四。那么我无须见亲见李四本人，也可以通过张三的背书而接受李四的证书。考虑到六度分隔假设，假如世界上所有人都使用 GPG 并积极为自己认识的人签名的话，并不需要多少中间链条，我就可以验证任何一个人的证书。这张网就是 GPG 信任网络。

显然，为了验证一个未知的证书是否可靠，我必须构建从我到他的整个信任链条。这便需要有一个中央服务器来存储所有人的证书和签名以供检索。这就是公钥服务器存在的意义。当我收到一份未知证书时，我会选择从公钥服务器拉取所有为他背书的人的证书，逐层上溯，看看是否能够找到一张已经被我信任的证书。如果能的话，就建立了到目标证书的信任路径。

为了保证这个机制可靠，全球的公钥服务器可以选择加入一个同步网络，以保证用户无论在哪里提交自己的证书，都可以在任何地方被检索到。任何一台服务器的下线也不会影响到用户的使用。这就是 SKS 网络。
这次投毒是怎么回事？

简单地说，有人恶意向服务器提交了对两个著名网友的签名背书。此事件中的受害者 Robert J. Hansen 的证书就被签名了 15000 次。因而任何人的 GPG 在尝试验证他的证书时，都会拉取 15000 个签名。而 GPG 在验证这么多签名的过程中会卡住很久。

由于被攻击的两个人在 GPG 社区中中地位很高，他们在 GPG 信任网络中处于相当核心的位置。这意味着——当你验证任意一份证书的时候，有不小的概率你会不小心拉取到他们俩的证书，然后你的 GPG 就会卡住。不但他们俩的证书没法用了，他们俩签名过的证书也都面临危险，乃至于他们俩签名过的证书所签名的证书……

以上是一些事实描述，下面对涉及到的其它问题做一下分析和解说

为什么 SKS 可以被投毒而且无法修正？
由于GPG的去中心化设计， SKS 作为全球密钥同步网络，被设计为上面的任何内容都不允许被删除——这样任何政府和公司都无法摧毁这个同步网络或要求删除信息。

然而，这个”永远不能删除”的设计在今天为 SKS 带来了许多问题。签名投毒只是其中之一
SKS 的其它挑战

和区块链之类的在设计之初就被设计为”永不删除”的服务类似，SKS 也有类似的问题：
1. 欧洲 GDPR 的要求。GDPR 要求服务商提供删除个人信息的选项：而区块链或 SKS 都不能满足此要求。故而一个公开的 SKS 服务器在欧洲处于违法状态
2. 蓄意在”永不删除”服务中存入违法信息，比如说儿童色情，将使所有节点的运营者面临刑事起诉。
3. 被人滥用。此次投毒是一个典型的滥用。任何”永不删除”的服务都有可能被人滥用于文件存储服务。然而对于区块链来说，毕竟存储是有成本的，将大块头数据存入的成本太高。而对于纯粹靠公益运营的 SKS 来说，投毒者没有任何成本。故而攻击的可行性大大提高。
对 Linux 社区的影响

为了避免因为 SKS 投毒而导致 gpg 崩溃并进而无法更新软件包，预计各大发行版的 gpg 默认 key server 都将从开放的全球同步 SKS 切换为中心化的 key server/key directory。

当然，这对于 GPG 信任网络是一个极大的打击，没有全球同步人人可见的 SKS 网络，本就难以建立的 GPG 信任网络将更难以发挥其效果。

各大 Linux 发行版的 gpg 证书的可信度，也将退化为中心化的信任机制：简单地相信发行版网站所提供的公钥。如果发行版网站被黑，那么用户将完全不受保护。
本次投毒的背景

长期以来，GPG 和 SKS 的维护团队动作缓慢，许多陈年 pull request 没有得到及时的处理，他们对待许多提 issue 的人的态度也伤到不少玻璃心的人。

我很怀疑这次投毒并非偶然，而是蓄意报复。
GPG 的未来

SKS 被摧毁，从根本上结束了 GPG “信任网络”的基础——虽然说 GPG 的用户从来都很少，这个”信任网络”一直都不能有效发挥作用，但现在则是再也不可能存在一个完整的”Web of Trust”了。

GPG 长期以来因为高使用门槛，用户不友好而无法流行。以后不用 GPG 的理由又多了一个：连它理想中的 web of trust 都不复可能，那么它也就不过是一个过时的加密软件而已。

如果不考虑“信任网络”这个理想，而只将它用于一般的加密、认证之用的话，在 SKS 之外还有很多公钥服务器可以使用。

比如说 keys.openpgp.org 就是一个新的试图解决滥用和隐私问题的 key directory。只有邮箱被验证之后才能发布邮箱地址，用户随时可以要求删除自己的个人信息。可惜它是一个中心化的服务，并不能防范单点故障。另外由于 GPG 团队的极低效率，目前 GPG 在导入其中无名公钥的时候仍然会报错。

不过个人倾向于，keybase.io 才是 GPG 的未来。keybase.io 解决了几点：将 GPG 用于日常聊天、网盘的易用性；用 github twitter 等帐户关联用户身份，使得用户无需建立”Web of Trust”就可以在相当程度上相信身份认证的可靠性。同时，它又不是一个像SSL证书一样完全中心化的设计：keybase.io 虽然扮演了一个集中目录的角色，但所有的加密都由用户端完成，所有的跨站身份认证都可以由用户在不依赖 keybase.io 的情况下独立验证。

我的 keybase：https://keybase.io/wangxuan

关于文本编辑器的一点想法

在强迫自己用VIM写了三篇 paper 之后，我觉得我的 VIM 终于可以出师了。现在开始了 Emacs 的折腾之路。
这其间有几点感触

掌握新的编辑器的最佳方法是逼自己用它完成一个大项目。每天每一步都去想：如何能让操作更方便一些？

VIM 和 Emacs 虽然说总被奉为神器，但确实已经开始显露疲态——负的历史包袱太重。就特殊用途来说，自然和大型 IDE 难以比肩，现在连 VSC 这样的新兴编辑器也要追不上了。
然而它们的魅力在哪里？在于——当你只是为了某个小任务想扩展一点功能的时候，用 VIM/Emacs 可以在极短时间内完成——而用 VSC 这样的编辑器，可能就必须要开发新的插件了。TypeScript 什么的门槛再低，也没有一行 VIM 宏来得快。
但是当使用者希望有像 IDE 一样的复杂支持时，VIM/Emacs 毕竟还是小众工具，开发者群体和 VSC 这样火爆的当代编辑器自然有些逊色。大部分插件都属于个人作品，加之UNIX哲学的影响，往往需要组合使用不同插件才能完成某个复杂工作环境的搭建——当然这也是折腾开源软件系统的乐趣之一。可是，对于追求稳定性的人来说，开源软件的频繁更新和复杂的依赖关系往往导致上手之后层出不穷的 bug 。

所以，VIM/Emcas 在当今的意义在哪里呢？
VIM 的文本编辑操作经过历史的检验，恐怕在脑机接口出现之前，都会是效率最高的操作方式。现在的大型IDE一般也提供了 VIM 模式的支持，甚至于对 VIM 宏和 ex mode 的支持。一味坚持原教旨 VIM 而拒绝这些先进工具显然是不明智的。
而 Emacs 恐怕主要的用户群体将一直会是有着造轮子爱好的人。只打算装装插件开箱即用的人，不一定适合使用 Emacs。不过要是用一个软件解决从上网、电邮、聊天到煮咖啡的所有需求，大概 Emacs 生态仍然是目前唯一的选择。

不过呢，所有的东西都自带一个文本编辑器。Word 里有一个，WordPress 里有一个，所有的 IDE 里都有一个（有些自带的编辑器还非常烂！）。还有很多数不胜数的流行几年就没人用的东西。文本编辑确乎是永远存在的需求——在脑机接口取代键盘之前——如果说，一定要精通一个文本编辑器（精通所有的软件里带的文本编辑器太浪费时间了；什么都不精只会用鼠标点点点效率也确实低）的话，VIM/Emacs 仍然是不二选择。