Soul Of Free Loop » 网络

特斯拉听播客的几种姿势

Uranus Zhou — Sun, 13 Aug 2023 08:33:05 +0000

去年购买的特斯拉 Model Y 标准续航版，目前已经开了差不多 16000 公里，家人用下来总体还是比较满意的。为了方便实时路况导航和听歌之类的，我还订购了 ¥9.99 / 月的高级车载娱乐服务包。一般如果开车的路程稍微长一点，我都习惯听一听订阅的各种播客来打发时间。

自带喜马拉雅

特斯拉默认只能用自带的喜马拉雅来听播客，虽然喜马拉雅的特斯拉车机版本已经比 Android 版本的喜马拉雅干净清爽多了，不过喜马拉雅也有一些限制，主要是不能自己添加 RSS 订阅源，另外基本没有英文的播客节目，有一些不太和谐的中文播客也没有，或者是只有中国版。

当然如果你只是需要在路上简单听一些常见的中文播客，那特斯拉自带的喜马拉雅应该也比较适合了。

第三方播客服务

不过还好特斯拉车机还是带了一个还算能用的浏览器，我们就可以通过访问其它播客服务网站来自由听播客了，主要需求还是：

支持自行添加播客 RSS 订阅源；
由于直接使用特斯拉自带的流量卡，需要国内能直接访问，也不想在特斯拉上折腾翻墙了；
播客节目的播放历史、进度最好支持在云端保存，这样在其它设备上访问播客服务网站或使用相应的 App 就能同步使用了。

目前特斯拉自带的 QQ 音乐、网易云音乐、喜马拉雅等车载娱乐服务在进行账户登录时，都需要对应的手机端 App 来扫码登录。如果在特斯拉上通过浏览器访问播客服务，也需要考虑账户登录的问题。由于特斯拉浏览器自带的输入法功能有限，也有点难用，使用第三方播客服务进行输入用户名和密码等登录操作最好也别太复杂。

Cloud Caster

Cloud Caster 本来是我首选的播客服务，基本能满足上面所有的需求，Cloud Caster 没有移动端 App，只要有浏览器就可以访问收听播客，播放列表和进度也能通过云端同步。

Cloud Caster 主要专注于收听播客功能，没有提供播客托管以及社区、评论之类乱七八糟的功能，其界面也比较清淡克制：

不过像上面截图的清淡克制效果也是有前提的：浏览器需要开启 Ad Block 之类的广告过滤功能，否则页面的左边、右边以及下方都有显眼的广告。当然，目前 Cloud Caster 基本是由网站主个人维护的，也没有什么商业支持，因此网站上加上这些广告来覆盖服务器支出我觉得也很正常。

特斯拉自带的浏览器并不支持像广告过滤之类的扩展功能，因此如果要在车上使用 Cloud Caster 就必须忍受广告了。如果你喜欢 Cloud Caster 的服务，可以通过他们的捐助页面来支持一下咯。

Cloud Caster 只支持网站的用户名和密码登录，登录时选中记住用户选项，也可以保存用户会话一段时间，偶尔需要输入用户名和密码重新登录也还能接受。

另外 Cloud Caster 目前也有点小问题，主要体现在某些像小宇宙播客之类的 RSS 源可能无法正常解析，或者无法更新最新的节目，所以我也基本是当作备用。

Podyssey

Podyssey 是我在发现 Cloud Caster 的问题后发现的另一个播客服务，Podyssey 主要特点在于提供了一个给众多用户发现和讨论 Podcast 播客节目的平台，其首页就是 Discover 发现界面：

Podyssey 也为 Podcast 播客创作者提供服务，创作者可以添加和分享自己录制的播客节目，并与收听者进行互动，不过看起来并没有播客音视频的托管服务。

Podyssey 也有 Android 和苹果的移动端 App，不过还好都没有广告，虽然界面看起来都稍微有点简陋：

使用一段时间之后我发现，Podyssey 的主要问题在于无法通过云端保存播客节目的播放进度，无论 App 端还是 Web 端，播放进度都是保存在客户端本地的，当然手机 App 端的播放进度也无法同步到 Web 浏览器端，不过这个其实对我来说影响倒是不大。

然而另外一个问题就稍微有点不能接受，虽然我订阅的播客基本都能在 Podyssey 中找到，但 Podyssey 其实并没有提供通过 RSS 源来订阅播客的功能，这样就显得稍微有点封闭了。

Podyssey 还存在用户登录方式比较奇葩的问题，默认只能输入邮箱地址登录，然后需要在收到的邮件里点击 Podyssey 发送的临时登录地址就可以自动登录。

这样在电脑上当然没什么问题，不过在车上登录就需要多一步把手机邮箱里的临时登录地址发到车上的步骤，登录操作虽然只需要偶尔做一下，但在特斯拉上使用 Podyssey 还是显得有点麻烦的，就继续当备用服务了。

自建 Podgrab

用了一段时间上面的 Cloud Caster、Podyssey 还有其它第三方播客服务，我发现这些服务基本都有一些或大或小的限制或问题，最终还是倾向自建 Podcast 播客服务，搜索了一番之后，还是找到了 Podgrab 这个开源项目。

Podgrab 项目的官方定位就是 self-hosted podcast manager，支持通过 RSS 源来订阅播客（也可以直接搜索订阅 iTunes 上的播客），当然顺带也支持 OPML 的导入和导出，还可以自动下载新的播客节目并进行管理，并附带了一个比较简单的播客播放器。Podgrab 还可以对播客节目进行标记，方便后续进行快速筛选查看。

由于 Podgrab 后台程序是由 Golang 编写的，因此天然就可以支持跨平台使用。如果你的服务器或者 NAS 存储支持 Docker 功能，那可以直接使用下面官方的镜像地址进行安装：

https://hub.docker.com/r/akhilrex/podgrab/

我为了使用方便，就直接在目前网站所在的 VPS 服务器上运行的，不过由于没有自带 Docker 支持，就先在 Linux 系统上编译好之后上传到 VPS 系统里运行了。Podgrab 的编译操作也很简单，只要安装了 Golang 环境，按照官方的 Building from source / Ubuntu Installation Guide 文章来编译应该就没什么问题。

VPS 服务器上最好单独指定一个目录来存放 Podgrab 程序和相关的下载文件，例如我建立了一个 /usr/local/bin/podgrab 目录，然后把编译好的 podgrab 可执行程序文件也上传到这个目录里。

其次是最重要的 Podgrab 配置文件，在刚才的目录下新建一个 .env 环境变量配置文件：

root@debian:/usr/local/bin/podgrab# cat > .env 
CONFIG=.
DATA=./assets
CHECK_FREQUENCY=30
PASSWORD=XXXXX
PORT=8080

Podgrab 项目主页也有环境变量的说明，主要是：

CHECK_FREQUENCY：检查新播客节目的间隔时间，以分钟为单位；
PASSWORD：设置密码认证，默认为空就是不需要密码认证，如果像我一样需要在 VPS 服务器上运行 Podgrab，强烈建议启用密码认证；
PORT：Podgrab 的监听端口，默认为 8080。

配置完成之后，就可以直接运行 ./podgrab 命令启动 Podgrab 了，你也可以根据需要按照官方的说明自己配置成服务方式来运行哦。

最后使用 http://host:8800（假设用的就是默认端口）就可以直接访问 Podgrab 管理界面了，如果启用了密码认证，需要注意用户名是固定的 podgrab。

Podgrab 默认的深色风格界面还是挺清爽耐看的，而且和特斯拉的车机系统界面也比较搭，首页可以选择以网格或列表的形式显示：

节目列表界面也就是显示标题、描述以及一些操作按钮：

由于我只需要能在特斯拉的浏览器打开 Podgrab 听播客，而且自带了高级车载娱乐服务包，完全可以在行驶途中使用车载流量播放播客节目，因此也基本不需要 Podgrab 的播客节目下载功能，为了节省 VPS 服务器的存储空间，我在 Podgrab 的设置界面把以下选项也关闭了：

Download episodes whenever new podcast is added
Automatically download new episodes to the disk

这样我在订阅了 27 个播客，并默认缓存所有节目信息后，VPS 服务器的存储空间也就占用了不到 30MB。

Podgrab 自带的播放器界面看起来就稍微有点简陋，不过在车上也够用了：

需要说明的是虽然 Podgrab 内播客节目的播放完成状态是保存在服务器上的，无论在什么客户端使用浏览器打开 Podgrab 看到的播放是否状态是自动同步的；但是具体某个节目的临时播放进度是保存在客户端浏览器本地的，不过实际用起来也基本没什么影响，而且得益于 Podgrab 项目是开源的，如果需要在服务器上保存节目的播放进度也可以自己修改代码来实现哦。

另外即使开启了密码认证，我们也可以使用 http://podgrab:PASSWORD@host:8800 形式的地址直接指定用户名和密码来访问 Podgrab，然后我们把这个地址添加到特斯拉浏览器的收藏夹，这样就能实现打开浏览器点击一下就进入 Podgrab 了，用起来也比 Cloud Caster 和 Podyssey 更加便利了。

综合对比下来，目前看起来还是 Podgrab 自建的方式更符合我的需求，我和夫人在驾车时试用 Cloud Caster 和 Podyssey 一段时间后，现在都换 Podgrab 来收听播客了。Podgrab 除了因为 VPS 服务器在国外加载节目列表偶尔稍等慢一点之外，用起来还是很顺畅的，后面有空了我再改一下 Podgrab 代码来实现保存播放进度到服务器，最后祝大家玩的开心哦。

香橙派R1 Plus LTS软路由体验

Uranus Zhou — Sun, 21 Aug 2022 12:32:40 +0000

去年家里装修好之后为了一步到位就打算把无线网络也升级到 WiFi 6 了，不过可惜买的时候没注意，选了有点坑的红米 AX3000 路由器（不是老的红米 AX6，这款的实际产品型号为：RA81）。这款路由器用的是高通 IPQ5000 处理器，集成 256MB 内存，WiFi 6 功能用起来虽然也没有太大的问题，只是开机运行时间久了总会有卡卡的感觉，最主要小米的魔改系统没有给 SSH 权限，而网上其它小米路由器的破解 SSH 方法对这款路由器并不起作用。

最近我想了想还是准备上个采用标准 OpenWRT 系统的软路由，红米 AX3000 路由器就准备只用来发射 WiFi 信号了。软路由原本考虑很多网友用过的友善 NanoPi R2S，只是最近这款软路由的溢价实在有点多，一番了解之后还是定下了迅龙推出的与 R2S 配置基本相同的 Orange Pi R1 Plus LTS 软路由。

介绍

R1 Plus LTS 软路由的基本硬件参数如下：

项目	内容
CPU	Rockchip RK3328
GPU	Mali-450MP2
内存	1GB LPDDR3
WAN	裕太微 YT8531C 10M/100M/1000M 以太网
LAN	Realtek RTL8153B 10M/100M/1000M USB 以太网
尺寸	63mm X 60.6mm X 27.25mm
重量	175g

其实香橙派之前还出了一款 R1 Plus 软路由，与我买的 R1 Plus LTS 区别也很小：

R1 Plus 用的是 1GB DDR4 内存；
R1 Plus 的 WAN 口使用的是 Realtek RTL8211E PHY。

所以 R1 Plus LTS 相当于是 R1 Plus 的低配版，只是可能由于芯片短缺等原因 R1 Plus 现在也基本上买不到了。

我购买的 R1 Plus LTS 软路由是自带官方金属外壳的，而且开发板本身都已经装好固定了的，因此主板本身我也就没拆了，看看软路由的外观：

前面是 TF 卡槽以及 SYS、LAN、WAN 指示灯，后面就是供电接口以及两个网口了。

本来打算用闲置的华为手机充电器，又考虑到放在家里需要长期稳定运行，我也顺便买了官方的 5V 3A USB Type-C 电源适配器：

系统

我找了一张老的 8GB TF 卡做系统盘，为了稳定也用的是官方提供的最新 OpenWrt 21.02.1 r16325-88151b8303 版本系统，也不考虑第三方固件提供的各种花里胡哨的功能了。

为了方便我也没有使用官方用户手册里推荐的 Win32Diskimager 或者 balenaEtcher 之类的工具来烧写镜像，直接用 Linux 自带的 dd 命令进行烧写：

备注

我的笔记本自带了 PCIe 的读卡器，所以这里的 dd 命令写的是 /dev/mmcblk0 设备，如果用的是 USB 读卡器，应该就要换成 /dev/sdb 之类的设备。

~# dd if=openwrt-rockchip-armv8-xunlong_orangepi-r1-plus-lts-ext4-sysupgrade.img of=/dev/mmcblk0 bs=1024k

由于 dd 命令没有校验的功能，烧写完成之后可以强制检查一下系统是否正确：

~# e2fsck -f /dev/mmcblk0p2

系统烧写完成之后就可以插到软路由上启动了，OpenWRT 系统第一次启动的时候会自动扩容 rootfs 分区，启动完成之后可以登录系统确认 rootfs 分区大小是否正确。

首先通过 SSH 登录或者 LuCI Web 管理界面修改 OpenWRT 的镜像源，这里我用的是清华的镜像源：

~# cat /etc/opkg/distfeeds.conf
src/gz openwrt_core https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/targets/rockchip/armv8/packages
src/gz openwrt_base https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/packages/aarch64_generic/base
~# cat /etc/opkg/customfeeds.conf
src/gz openwrt_luci https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/packages/aarch64_generic/luci
src/gz openwrt_packages https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/packages/aarch64_generic/packages
src/gz openwrt_routing https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/packages/aarch64_generic/routing
src/gz openwrt_telephony https://mirrors.tuna.tsinghua.edu.cn/openwrt/releases/21.02.1/packages/aarch64_generic/telephony

香橙派官方提供的 OpenWRT 系统自带了 Adblock、Squid、Transmission 甚至 Docker 等软件的支持，用户也可以自行卸载，例如卸载 MiniDLNA：

~# opkg remove luci-i18n-minidlna-zh-cn luci-app-minidlna minidlna

通过 SSH 登录可以看到 OpenWRT 系统的 Linux 内核是 5.4 版本的，应该也够用了：

~# uname -a
Linux R1PlusLTS 5.4.154 #0 SMP PREEMPT Sun Oct 24 09:01:35 2021 aarch64 GNU/Linux

然后是 CPU 信息：

~# cat /proc/cpuinfo
processor    : 0
BogoMIPS    : 48.00
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant   : 0x0
CPU part    : 0xd03
CPU revision  : 4

LuCI 问题

值得一提的是我使用 Chrome 浏览器访问 OpenWRT 的 LuCI Web 管理界面经常出现类似 _(...).format is not a function 这样的报错，控制台还有其它错误：

A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received

后来发现使用 Chrome 无痕式窗口访问 LuCI Web 界面就没有问题，因此怀疑是某些 Chrome 扩展导致的，经常一番禁用扩展并测试，确认是由 TronLink 这个波场官方的钱包导致的，禁用 TronLink 扩展就可以正常访问 LuCI 界面。

不过为了能正常使用 TronLink 钱包，我还是在 TronLink 扩展的详情页将 允许此扩展程序读取和更改您在所访问的网站上留存的所有数据 选项由 在所有网站上 改为了 点击时，这样 LuCI 界面和 TronLink 就都可以用了。

性能

这里我就不做常见的 CPU 性能、加解密性能测试了，因为 RK3328 的性能已经有好多网友测试过了，我主要关注 LAN 口 RTL8153B USB 网卡的性能。

我的笔记本直接带了千兆有线网卡，这样我就将笔记本通过千兆网线接到软路由的 LAN 口，用 iperf 命令做一下简单的测试了，先看看 LAN 口接收数据的性能：

~# iperf -s -w 512K
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.00 MByte (WARNING: requested 512 KByte)
------------------------------------------------------------
[ 4] local 192.168.2.1 port 5001 connected with 192.168.2.57 port 65244
[ ID] Interval    Transfer   Bandwidth
[ 4] 0.0-30.0 sec 3.31 GBytes  949 Mbits/sec

接着我又测试了 LAN 口发送数据的性能：

root@R1PlusLTS:~# iperf -c 192.168.2.57 -w 512K -t 30
------------------------------------------------------------
Client connecting to 192.168.2.57, TCP port 5001
TCP window size: 1.00 MByte (WARNING: requested 512 KByte)
------------------------------------------------------------
[ 3] local 192.168.2.1 port 44562 connected with 192.168.2.57 port 5001
[ ID] Interval    Transfer   Bandwidth
[ 3] 0.0-30.0 sec 3.30 GBytes  946 Mbits/sec

总结

最后我把 R1 Plus LTS 软路由的联网配置好之后，将原来的红米 AX3000 路由器的 WAN 口接到 R1 Plus LTS 的 LAN 口，并把 AX3000 从 普通路由 模式切换为 有线中继 模式，这样原有的手机之类的无线终端设备就能继续上网了：

由于 R1 Plus LTS 软路由只有一个 LAN 口，家里的 NAS 服务器只能接在红米 AX3000 路由器上了。还好 AX3000 使用有线中继模式之后，终端设备与软路由也还在同一网段，而且上面的测试结果可以看出软路由的 LAN 口性能也不是瓶颈，我用支持 WiFi 6 的电脑和手机访问 NAS 服务器的速度也没什么问题，可以满足日常使用需求了。

最后说一下 R1 Plus LTS 软路由的散热，我购买的是自带官方金属外壳的版本，这两个月连续运行下来我发现也挺稳定的，通过命令可以查看 CPU 温度：

root@R1PlusLTS:~# cat /sys/class/thermal/thermal_zone0/temp
56818

上面结果中的 57 摄氏度是在南京接近 40 度的高温下室内不开空调看到的，实际使用下来我还没有遇到温度超过 60 摄氏度的情况，看起来挺过这个最热夏天之后，R1 Plus LTS 软路由就可以留下来暂定长期使用了。

使用kcptun曲线访问Arukas容器

Uranus Zhou — Wed, 06 Mar 2019 17:08:16 +0000

新版 Arukas 容器现状

2017 年我写了两篇介绍日本 Arukas 樱花容器服务的文章，那个时候主要用来跑 Shadowsocks 梯子服务。后来不知道是否因为国内用户蜂拥而至，Arukas 容器基本所有的 IP 地址都被封了，接着 Arukas 也停止提供服务，直到去年才恢复。最近住处的移动宽带不知何故连接一直使用的美国 VPS 速度很慢，因此我想着可以试试新版本 Arukas 容器的效果。

恢复后的新版 Arukas 服务直接把原来的账户都给删除了，用户都需要重新注册，实际使用还必须绑定有效的信用卡，容器配置可以参考其官网（需要爬墙）：

https://arukas.io/en/#pricing

每个账户可以最多创建一个免费容器，免费容器配置如下：

每个月 730 小时运行时间；
0.1 vCPU；
128 MB 内存；
100 GB 流量；
仍然不支持外部存储；
支持绑定域名（针对 Endpoint）；
仍然只支持 Docker Hub 库，而且只支持修改 CMD 启动命令。

可以看到新版 Arukas 免费容器的配置是有点捉襟见肘，还好我也只是拿来访问 Google 服务之类的，对流量需求不大，如果你经常要看 YouTube 视频之类的，那就不用考虑 Arukas 容器咯。

按照原来写的 Arukas容器使用ge.tt替代Endpoint域名文章重新部署 Shadowsocks 容器，我发现还算欣慰的是 Arukas 提供的 Endpoint 域名还没有被封锁，容器内 Web 服务器提供的内容可以通过 Endpoint 域名访问。

如果你只需要跑一个简单的静态网站，对资源和流量要求也不高的话，那 Arukas 容器也是挺不错的，毕竟还支持绑定自定义的域名。不过 Arukas 的 Endpoint 域名转发服务仍然只支持 HTTPS 访问，而且 Endpoint 地址应该只对容器开放的第一个内部端口有效，只支持 HTTP 协议，不支持 TCP 或者 UDP。如果用 Arukas 容器来跑动态网站，那有可能效果不太理想。

不出意料的是我准备搭梯子的时候，发现墙对 Arukas 封锁的比较彻底，测试了多个 IP 地址都无法正常连接，为此考虑修改原来的容器试试通过 kcptun 进行转发访问。

Shadowsocks 容器修改

我原来制作的 Arukas 专用 Shadowsocks 容器是基于 Baseimage-docker 镜像修改的，增加 kcptun 支持也很简单。访问 kcptun 的官方 GitHub release 页面：

https://github.com/xtaci/kcptun/releases

下载 Linux amd64 版本的 kcptun 程序，我们也只需要将服务端程序加到原来的 Shadowsocks 容器镜像中，并简单修改下 /etc/my_init.d/01_start_ss_ssh.sh 启动脚本（支持 kcptun 的修改已高亮显示）：

#!/bin/bash

# Enable SSH
rm -f /etc/service/sshd/down
/etc/my_init.d/00_regen_ssh_host_keys.sh
touch /etc/service/sshd/down

# Setup SSH key
if [ "x$SSH_AUTHORIZED_KEYS" = "x" ]; then
	/usr/sbin/enable_insecure_key
else
	mkdir ~/.ssh
	echo "$SSH_AUTHORIZED_KEYS" | sed 's/\\n/\n/g' > ~/.ssh/authorized_keys
	chmod 400 ~/.ssh/authorized_keys
fi

# Start web server
env | grep -E '^MARATHON_HOST=|MARATHON_PORT_' > /home/wwwroot/default/marathon.conf
if [ "x$MARATHON_HOST" != "x" ]; then
	getent hosts $MARATHON_HOST | awk '{print "MARATHON_HOST_IP="$1; exit;}' >> /home/wwwroot/default/marathon.conf
fi

start-stop-daemon -S -b -n tmp-httpd -d /home/wwwroot/default -x /usr/bin/python3 -- -m http.server 80

# Start ShadowSocks
env | grep '^SHADOWSOCKS_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	SS_NAME="${T_NAME:17}"
	echo "${!T_NAME}" > /etc/shadowsocks-libev/${SS_NAME}.json
	start-stop-daemon -n ss-$SS_NAME -x /usr/bin/ss-server -b -S -- -c /etc/shadowsocks-libev/${SS_NAME}.json -u --fast-open
done

# Start kcptun
env | grep '^KCPTUN_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	KCP_NAME="${T_NAME:12}"
	echo "${!T_NAME}" > /etc/kcptun/${KCP_NAME}.json
	start-stop-daemon -n kcp-$KCP_NAME -x /usr/bin/kcptun_server -b -S -- -c /etc/kcptun/${KCP_NAME}.json
done

if [ "x$GETT_TOKEN" != "x" ]; then
	if [ "x$HOME" = "x" ]; then
		export HOME="/root"
	fi
	echo -n "$GETT_TOKEN" > ~/.gett-token
	if [ "x$GETT_SHARE_NAME" != "x" ]; then
		python3 /usr/local/gett/uploader.py -l http://ge.tt/$GETT_SHARE_NAME | awk '{if (substr($5,1,13)=="http://ge.tt/") {print $5;}}' | xargs python3 /usr/local/gett/uploader.py --delete
		python3 /usr/local/gett/uploader.py -s http://ge.tt/$GETT_SHARE_NAME /home/wwwroot/default/marathon.conf
	fi
fi

exec /usr/sbin/sshd -D -e -u 0

新版支持 kcptun 访问 Shadowsocks 的 Arukas 专用容器安装包下载地址，仍然支持 SSH 登录以及通过 Endpoint 地址或者 ge.tt 分享获取容器当前地址和端口：

https://zohead.com/downloads/arukas-baseimage-xenial-ss.tar.gz

原有的 CMD 启动命令以及以 SHADOWSOCKS_CFGS_ 开头的 Shadowsocks 配置变量和 SSH_AUTHORIZED_KEYS SSH 证书变量配置都没有变化。

此次增加了以 KCPTUN_CFGS_ 开头的 kcptun 配置变量，当然别忘了容器端口配置中也得指定一个新的 UDP 端口给 kcptun 服务使用。

例如我现有的 Shadowsocks 服务配置变量：

SHADOWSOCKS_CFGS_xxx={ "server":"0.0.0.0", "server_port":17374, "local_port":1080, "password":"arukas-ss-svr", "timeout":30, "method":"aes-256-cfb" }

现在需要在 Arukas 容器中运行 kcptun 服务器进行 UDP 转发，可以添加一个 kcptun 配置变量（仍然是 JSON 格式，需要写成一行）：

KCPTUN_CFGS_xxx = { "listen": ":29900", "target": "127.0.0.1:17374", "key": "arukas-kcp-svr", "crypt": "xor", "mode": "fast2", "mtu": 1350, "sndwnd": 128, "rcvwnd": 128, "datashard": 0, "parityshard": 0, "dscp": 46, "nocomp": true, "acknodelay": false, "nodelay": 0, "interval": 40, "resend": 2, "nc": 1, "sockbuf": 4194304, "keepalive": 10, "log": "/var/log/kcptun.log" }

这里我指定 kcptun 服务器绑定默认的 29900 UDP 端口（Arukas 容器端口配置中即需要开放 29900 UDP 端口），转发地址即指向本地的 Shadowsocks 服务器端口。

提示

上面贴出来的我使用的 kcptun 配置并不是最佳配置，只是由于我的 OpenWRT 路由器运算能力比较孱弱，避免出现路由器上的 kcptun 客户端导致 CPU 占用过高的问题。

kcptun 的配置稍微有点复杂，需要根据用户实际网络环境修改，这里我就不详细介绍了，请参考 GitHub 项目主页的说明。

Android kcptun 测试

我们可以首先用 Android 手机测试通过 kcptun 连接 Arukas 容器的 Shadowsocks 服务，在手机上安装 Shadowsocks App 和专用的 kcptun 插件。

安装完成之后 Shadowsocks 配置文件中就可以选择 kcptun 插件，需要注意你如果使用的是像我的 Nubia Z17 这种魔改版手机，可能需要在 手机管家 之类的系统设置中开启 kcptun 的自启动权限，防止出现 Shadowsocks App 无法启动 kcptun 的问题。

Shadowsocks App 连接的服务器地址也需要更换为 Arukas 容器实际地址和 kcptun 服务的外部访问端口，kcptun 插件的配置则保持与服务端一致即可，我的配置如下：

dscp=46;nocomp;mtu=1350;datashard=0;parityshard=0;mode=fast2;key=arukas-kcp-svr;crypt=xor

Android kcptun 插件的配置使用 key=value 的格式，中间以分号隔开，如果只有 key 没有 value 则表示启用该参数（true），具体配置参数可以点击 kcptun 插件的 ? 按钮查看详细说明。

OpenWRT 自动更新配置脚本

使用 kcptun 之后，OpenWRT 路由器上的 Shadowsocks 配置也不太一样了，例如我的 /etc/shadowsocks-arukas.json 配置文件就可以保持不变了（固定连接本地 kcptun 地址和端口）：

{
	"server" : "127.0.0.1",
	"server_port" : "17374",
	"password": "arukas-ss-svr",
	"local_port": "1080",
	"timeout" : "30",
	"method": "aes-256-cfb"
}

相应的增加 kcptun 客户端的配置文件 /etc/kcptun-arukas.json，key 密码与容器中 kcptun 服务器密码一致，remoteaddr 就是容器 kcptun 服务 UDP 监听的外部访问地址和端口：

{
"localaddr": ":17374",
"remoteaddr": "",
"key": "arukas-kcp-svr",
"crypt": "xor",
"mode": "fast2",
"mtu": 1350,
"sndwnd": 128,
"rcvwnd": 128,
"datashard": 0,
"parityshard": 0,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 40,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

为了支持 kcptun，我也稍微改了下 OpenWRT 路由器的 arukas-ss.sh 自动更新配置脚本，为了使用方便我把 kcptun 客户端的启动和停止操作也放到 /etc/init.d/shadowsocks 服务脚本中了，其它路由器请自行修改此脚本：

#!/bin/sh
ARUKAS_ENDPOINT=""
GETT_SHRNAME=""
RESTART_SHADOWSOCKS="no"

[ $# -ge 2 ] || exit 1

[ -f /tmp/.marathon.conf ] && mv /tmp/.marathon.conf /tmp/.marathon.conf.bak

IND=0
while [ $IND -lt 5 ]; do
	let IND++
	[ -f /tmp/.marathon.conf ] && rm -f /tmp/.marathon.conf
	if [ "x$GETT_SHRNAME" != "x" ]; then
		T_FILEID=`curl -s -k -f http://api.ge.tt/1/shares/$GETT_SHRNAME | sed -e 's/^.*"fileid"[^:]*:[^"]*"//' -e 's/".*$//'`
		if [ "x$T_FILEID" != "x" ]; then
			curl -s -k -f -o /tmp/.marathon.conf -L -e "http://ge.tt/$GETT_SHRNAME" "http://api.ge.tt/1/files/$GETT_SHRNAME/$T_FILEID/blob?download"
			[ $? -eq 0 ] && break
		fi
	fi
	curl -s -k -f -o /tmp/.marathon.conf https://$ARUKAS_ENDPOINT.arukascloud.io/marathon.conf
	[ $? -eq 0 ] && break
	sleep 1
done

[ -s /tmp/.marathon.conf ] || exit 1
echo "Fetch server config after $IND tries."

if [ -f /tmp/.marathon.conf.bak ]; then
	cmp -s /tmp/.marathon.conf /tmp/.marathon.conf.bak
	if [ $? -eq 0 ]; then
		rm -f /tmp/.marathon.conf
		exit 0
	fi
fi

. /tmp/.marathon.conf 2>/dev/null
if [ "x$MARATHON_HOST" = "x" ]; then
	rm -f /tmp/.marathon.conf
	exit 1
fi

if [ "x$MARATHON_HOST_IP" != "x" ]; then
	MARATHON_HOST="$MARATHON_HOST_IP"
fi

while [ $# -gt 2 ]; do
	CMD="echo \${MARATHON_PORT_$2}"
	TMP_PORT=`eval $CMD`

	if [ -f $1 -a "x$TMP_PORT" != "x" ]; then
		if [ "x$3" = "xshadowsocks" ]; then
			sed -i -e 's/"server"[^:]*:[^,]*,/"server" : "'$MARATHON_HOST'",/' -e 's/"server_port"[^:]*:[^,]*,/"server_port" : "'$TMP_PORT'",/' $1
			grep -q '^CONFIG.*='$1 /etc/init.d/shadowsocks
			[ $? -eq 0 ] && RESTART_SHADOWSOCKS="yes"
		elif [ "x$3" = "xkcptun" ]; then
			sed -i 's/"remoteaddr"[^:]*:[^,]*,/"remoteaddr" : "'$MARATHON_HOST':'$TMP_PORT'",/' $1
			grep -q '^KCPTUN_CONFIG.*='$1 /etc/init.d/shadowsocks
			[ $? -eq 0 ] && RESTART_SHADOWSOCKS="yes"
		fi
	fi
	shift
	shift
	shift
done

if [ "x$RESTART_SHADOWSOCKS" = "xyes" ]; then
	/etc/init.d/shadowsocks restart
fi

使用之前请修改脚本最上面的 ARUKAS_ENDPOINT 和 GETT_SHRNAME 变量，分别为 Arukas 容器的 Endpoint 名（Arukas Endpoint 地址可访问的情况下建议优先使用）和 ge.tt 分享名。

为了区分 Shadowsocks 和 kcptun 配置文件，我对脚本调用方式也做了修改，增加了指定配置类型的参数（shadowsocks 或 kcptun），例如我的 crontab 配置：

30 * * * * /etc/arukas-ss.sh /etc/kcptun-arukas.json 29900 kcptun

这样路由器就可以自动更新 kcptun 客户端配置文件中的 remoteaddr 项了。

我的渣渣移动宽带环境下电脑通过路由器 kcptun 爬墙看 YouTube 视频效果如下：

受限于路由器硬件的性能，Arukas 网络的 kcptun 速度并没有完全发挥出来，不过还是比原先的美国 VPS 要好多了，最后祝大家在开会的特殊阶段也能把梯子搭的开心。

广电宽带DNS访问某些国内网站的问题

Uranus Zhou — Sat, 28 Oct 2017 03:44:15 +0000

问题说明

有段时间没有更新博客了，最近全国都处于重要的开会期间，不出所料常用的爬墙路线都被各种封锁，而我在的住处使用的广电宽带也出幺蛾子了。前两周我发现突然无法访问 www.ip138.com、www.chinaz.com 之类的国内网站，浏览器上的表现似乎是没有正常打开连接就中断了。

通过在本地运行 nslookup 命令解析这些域名我才发现，这些网站在我的电脑上根本没有解析到任何有效的 IP 地址，难怪无法正常访问了。

为此我登录到 OpenWRT 路由器，直接在路由器系统上运行 nslookup 命令解析这些无法访问的域名，从返回的结果才看出端倪：

[root@PandoraBox:/root]#nslookup www.baidu.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.baidu.com
Address 1: 180.97.33.108
Address 2: 180.97.33.107

[root@PandoraBox:/root]#nslookup www.ip138.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.ip138.com
Address 1: ::ffff:172.30.1.23

[root@PandoraBox:/root]#nslookup www.dasai8.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.dasai8.com
Address 1: ::ffff:172.30.0.44
Address 2: 172.30.0.44

可以看到百度域名可以返回正确的结果，因此能正常访问。

无法访问的 www.ip138.com 和 www.dasai8.com 域名返回的则是诡异的 IPv6 和 IPv4 地址，实际上这两个网站从目前来看是不太可能部署了 IPv6 支持的，而且返回的结果中 172.30.1.23 和 172.30.0.44 也是明显的本地局域网地址。

到此我也大概了解原因了：

广电宽带不知道出于节省成本还是什么的考虑，对某些国内网站内容做了缓存，用户解析这些网站域名时直接返回广电网内缓存服务器的地址，这样访问起来也比较快。但不巧的是这些解析到的局域网服务器地址没有通过路由器正确返回给我使用的电脑，导致无法正常访问这些网站。

问题原因

目前的问题看起来出在路由器上了，为此需要检查路由器的 DNS 服务器设置。最后终于在 PandoraBox 的 “DHCP/DNS” 界面中找到的相关的 “重绑定保护” 设置，把默认选中的 “丢弃RFC1918上行响应数据” 勾去掉之后保存并应用就可以了。

这样修改之后，路由器就不会忽略内网地址的解析结果了。

现在再来看看修改之后 ping 这些网站的结果（广电宽带对于非广电内部网络的地址一般都是不允许 ping 的）：

(trusty)zzm@localhost:~$ ping -c 4 www.dasai8.com
PING www.dasai8.com (172.30.0.44) 56(84) bytes of data.
64 bytes from 172.30.0.44: icmp_seq=1 ttl=58 time=7.94 ms
64 bytes from 172.30.0.44: icmp_seq=2 ttl=58 time=9.74 ms
64 bytes from 172.30.0.44: icmp_seq=3 ttl=58 time=7.40 ms
64 bytes from 172.30.0.44: icmp_seq=4 ttl=58 time=9.97 ms

--- www.dasai8.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3037ms
rtt min/avg/max/mdev = 7.402/8.766/9.975/1.115 ms

(trusty)zzm@localhost:~$ ping -c 4 www.chinaz.com
PING www.chinaz.com (172.30.1.22) 56(84) bytes of data.
64 bytes from 172.30.1.22: icmp_seq=1 ttl=57 time=7.57 ms
64 bytes from 172.30.1.22: icmp_seq=2 ttl=57 time=9.66 ms
64 bytes from 172.30.1.22: icmp_seq=3 ttl=57 time=8.59 ms
64 bytes from 172.30.1.22: icmp_seq=4 ttl=57 time=10.8 ms

--- www.chinaz.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 7.573/9.177/10.870/1.230 ms

(trusty)zzm@localhost:~$ ping -c 4 www.baidu.com
PING www.a.shifen.com (180.97.33.107) 56(84) bytes of data.

--- www.a.shifen.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

可以看到前面两个域名的 ping 值显然是局域网内的结果，而 ping 百度则是 “正常” 地返回超时了 -_-#。

解决方法

经过后续测试我发现广电宽带甚至对土豆网这种级别的网站都做了缓存，解析时会返回 172.30.1.23 之类的局域网地址。

尽管可以忽略路由器 DNS 的重绑定保护机制，但访问这些网站完全使用广电缓存的话，很可能会出现网页不正确甚至被插广告的风险，为此我还是在路由器上开启了 pdnsd 服务，修改了 dnsmasq 配置文件，将这些可能被广电缓存的网站域名单独发给本地的 pdnsd 服务进行解析。

dnsmasq 配置文件类似这样：

server=/.google.com/127.0.0.1#5353
ipset=/.google.com/gfwlist
server=/.twitter.com/127.0.0.1#5353
ipset=/.twitter.com/gfwlist
server=/.facebook.com/127.0.0.1#5353
ipset=/.facebook.com/gfwlist
server=/.dasai8.com/127.0.0.1#5353
server=/.ip138.com/127.0.0.1#5353
server=/.chinaz.com/127.0.0.1#5353

前面几个是必须爬墙的域名，通过 pdnsd 解析并加入到名为 gfwlist 的 ipset 中，这样可以自动走 Shadowsocks ss-redir 线路，后面的几个常规情况下被缓存的域名则只是通过 pdnsd 解析。

pdnsd 服务器的配置是以 TCP 协议通过第三方的 DNS 服务器进行域名解析，考虑到 TCP 的 DNS 协议仍然会被广电给劫持的问题，还需要将 pdnsd 配置中的 DNS 服务器加入到 ipset 中，这样就可以让 pdnsd 的解析请求完全走 Shadowsocks 或者 OpenVPN 来避免污染了。

WordPress 3.8开启Google AMP的问题

Uranus Zhou — Tue, 01 Aug 2017 17:37:56 +0000

关于 AMP

Accelerated Mobile Pages（简称 AMP）是 Google 带领开发的开源项目，主要为了提升移动设备对网站的访问速度，大概包括 AMP HTML、AMP JS 和 AMP Cache 三部分，非常适合博客及新闻展示类的静态网站。

有关 AMP 的详细介绍可以参考其官方网站：

https://www.ampproject.org/zh_cn/

AMP 网页只能使用 AMP HTML 中允许的有限的标签，不允许使用 AMP Runtime、AMP Components 之外的 JS，而且 AMP Runtime、Components 都必须从 cdn.ampproject.org 加载，因此目前 AMP 网页都必须在翻墙状态下才能正常浏览。

AMP Cache 是负责缓存并传输 AMP 页面的 CDN 服务器，用户在 Google 移动端中点击 AMP 网站时，实际访问的是缓存过的页面。

WordPress 启用 AMP 的问题

WordPress 官方提供了 AMP 插件以支持直接为博客开启 AMP 加速，只是官方插件要求 WordPress 最低为 4.4 版本。

由于我的博客安装了 qTranslate 这款多语言插件，而该插件却只支持到 WordPress 3.8.1 版本，如果升级 WordPress 到最新版本，qTranslate 插件就会自动禁用。然而 qTranslate 插件是对 WordPress 数据库直接进行修改的，禁用之后博客文章就可能会同时显示多种语言的内容，这样显然是不可接受的。

虽然网上已经有人继承 qTranslate 原作发布了例如 qTranslate X 之类的支持新版本 WordPress 的插件，但为了数据安全（其实是懒）考虑我暂时还是不打算直接升级 WordPress 了。

不过还好我在 WordPress 插件库里找到一款看起来支持 WordPress 3.8 的 AMP 插件：AMP for WP，毕竟看此插件的介绍和评分都比官方的 AMP 插件要强哦，而且最低只要求 WordPress 3.0 版本。

AMP for WP 安装起来还是非常顺利的，插件选项里目前基本只提供了 Google Analytics UID 的设置选项，启用之后访问 AMP 版网站的方法是在地址后面加上 ?wpamp 后缀。

不过我刚开始测试访问 AMP 首页和文章就碰到问题了，直接没有任何显示了，看网页源代码输出信息不全，显然是 AMP for WP 插件对老版本 WordPress 兼容性还是有点问题。

修改 AMP for WP

首先修改 AMP for WP 插件的 wp-amp-ninja/admin/common.php 文件，打开 PHP 报错开关：

error_reporting(1);

这下访问博客首页和文章页面就能看到详细报错了：

Fatal error: Call to undefined function get_the_permalink() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-front.php on line 24

Fatal error: Call to undefined function the_posts_pagination() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/template/wpamp-content.php on line 53


Fatal error: Call to undefined function the_archive_title() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-functions.php on line 600

Fatal error: Call to undefined function the_archive_description() in /www/zohead.com/wp-content/plugins/wp-amp-ninja/includes/wpamp-functions.php on line 601

经过查阅 WordPress 官方文档发现：

get_the_permalink 函数在 WordPress 3.9.0 版本开始引入，其实就是 1.0.0 版本就已经有的 get_permalink 函数；
the_posts_pagination 函数在 WordPress 4.1.0 版本开始引入，一同引入的还有 the_posts_navigation 函数，与 get_the_permalink 函数一样都位于 WordPress 代码库的 wp-includes/link-template.php 文件；
至于 the_archive_title 和 the_archive_description 函数的功能比较类似，支持显示文章的标题和描述并在前后插入自定义代码，同样也在 WordPress 4.1.0 版本开始引入，位于 WordPress 代码库的 wp-includes/general-template.php 文件。

由此可见，AMP for WP 实际上应该至少要求 WordPress 4.1.0 版本，只是作者并没有测试过是否兼容较低版本的 WordPress。

不过还好我看了下 WordPress 最新 4.8 版本的代码，上面缺少的几个 WordPress 内置函数都是功能比较独立的。

因此我稍微修改了一下博客目录下的 link-template.php 和 general-template.php 文件，将最新版本的 get_the_permalink、the_posts_pagination、the_posts_navigation、the_archive_title、the_archive_description 函数实现分别 Backport 到 WordPress 3.8 版本。Backport 完成之后再访问博客首页和文章，就没有 PHP 报错了。

不过初步试用下来，我还是发现 AMP for WP 插件的一些小问题：

如果通过 qTranslate 插件访问博客的英文版本（通过增加 ?lang=en 地址后缀），对应的 AMP 版页面地址会不正确，AMP for WP 插件在转换地址时并没有考虑地址中会带有其它后缀的情况；
AMP for WP 对于带有多种语言标题的文章直接显示数据库中多种语言合并在一起的标题效果，而并不是 qTranslate 插件根据客户端语言自动处理后的效果，这个问题在我使用的几个 WordPress 主题中都不会出现；
文章中插入的多行代码被合并成一行显示了，这是明显不能接受的；
文章的中文发表时间无法正确显示，统一显示为当前日期。

第一个问题需要修改 AMP for WP 插件的 wpamp-front.php、wpamp-functions.php、wpamp-header.php 这几个文件中转换地址的代码，例如 wpamp-front.php 文件的修改：

 		$the_permalink = get_the_permalink( $post->ID );
 	}
 	
-	$the_permalink = rtrim( $the_permalink, '/' ) . '/';
+	$the_permalink = rtrim( $the_permalink, '/' );
 	$perma = strpos( $the_permalink, "?" );
 	if ( $perma === false ) {
+		$the_permalink .= '/';
 		$sConnector = "?";
 	} else {
 		$sConnector = "&";

第二个问题需要修改 wpamp-content.php 文件，文章标题要做 apply_filters 处理：

                 
                 	
-                    	 « post_title ?>
+                    	 « post_title, $prev_post->ID ); ?>
 					
 					
-                        post_title ?> » 
+                        post_title, $next_post->ID ); ?> »

第三个问题就比较简单了，将 simple_html_dom.php 文件中替换回车和换行符的处理去掉就可以了。

第四个文章发表时间的问题也可以修改 wpamp-content.php 文件简化处理：

                     
                     By 
-                    
-                    on 
+                    on

另外我还对 AMP for WP 插件的页脚处理做了点小修改，将页脚上切换到博客首页桌面版本的链接改为切换到当前文章的桌面版本，方便访问者使用。

总结

对 AMP for WP 插件修改完成之后就可以访问博客的 AMP 版进行验证了，例如我的博客的 AMP 版首页地址就是：

https://zohead.com/?wpamp

普通用户可以通过安装 Google 推出的 AMP Validator 官方 Chrome 扩展检测所访问的 AMP 站点是否配置正确。

网站所有者可以用 Google 搜索的 AMP 在线测试工具进行检测：

https://search.google.com/test/amp

输入要测试的 AMP 版网址就可以开始检测，另外这个测试工具的另一个好处就是检测通过之后可以直接把你的 AMP 站点提交给 Google，让 Google 搜索蜘蛛尽快收录并进行 CDN 缓存。

现在通过 Google 移动端（例如 Android Chrome 浏览器）搜索我的博客，应该就能在搜索结果里看到下面的 AMP 闪电标志了：

点击搜索结果，你会发现访问的其实是 Google 缓存过的 AMP 地址，下面地址只有移动端浏览器才会显示 AMP 网页：

https://www.google.com/amp/s/zohead.com/%3fwpamp

初步启用 AMP 的大体感受就是如果你的梯子还可以，那访问 Google 缓存过的 AMP 网站速度还是非常快的，我这里估计访问 AMP 版网站所需要的流量大概为桌面版本的 1/3。

后面有时间的话还是希望能对 AMP for WP 插件继续改进，例如支持其它的 AMP 后缀或者使用专门的 AMP 子域名方便自己的服务器进行缓存之类的，最后祝大家玩的开心。

OpenWRT实现OpenVPN按ipset自动分流

Uranus Zhou — Sun, 16 Jul 2017 04:35:35 +0000

接着上面一篇介绍 Windscribe 免费 VPN 的文章，住处的网络通过 OpenVPN 连接 Windscribe 之后虽然速度不快，但好歹广电宽带下没有之前用的几个 VPS 经常超时的问题了。因此想着最好能部署到现在用的 newifi mini 路由器上（毕竟已经刷了 PandoraBox 固件），目标就是能在路由器上用 OpenVPN 连接 Windscribe 并自动分流翻墙访问某些特殊的网站。

OpenWRT 安装使用 OpenVPN

首先在路由器上安装 OpenVPN 客户端：

[root@PandoraBox:/root]# opkg update
[root@PandoraBox:/root]# opkg install openvpn-openssl

把上篇文章中生成的 Windscribe OpenVPN 配置文件上传到 /etc/openvpn 目录，假设配置文件路径为 /etc/openvpn/windscribe.ovpn。

这里需要注意 OpenWRT 的 OpenVPN 客户端并不能像 Windows 等客户端那样提示用户输入 Windscribe VPN 连接用户名和密码，只能通过用户密码文件指定。我们需要手工生成用户密码文件 /etc/openvpn/windscribe.txt，文件格式为第一行用户名，第二行密码。

接着修改 OpenVPN 配置文件，增加一行指定用户密码文件：

auth-user-pass windscribe.txt

提示

如果你使用的 OpenVPN 客户端版本比较老（比如我的 PandoraBox 系统里安装的是 2.3.6-2 版本），可能不支持 Windscribe OpenVPN 配置文件里的 block-outside-dns 选项，如果 OpenVPN 运行报错的话可以注释掉这个选项。

然后修改 /etc/config/openvpn 配置文件增加一个新的 OpenVPN instance，新的配置名称不要与现有的重复即可：

config openvpn 'windscribe'
	option config '/etc/openvpn/windscribe.ovpn'
	option enabled '1'

剩下就是激活并启动 OpenVPN 客户端服务了：

[root@PandoraBox:/root]# /etc/init.d/openvpn enable
[root@PandoraBox:/root]# /etc/init.d/openvpn start

稍等一会，如果一切正常的话，用 logread 命令应该能看到 OpenVPN 的连接日志：

[root@PandoraBox:/root]# logread -f
Fri Jul  7 00:02:13 2017 daemon.notice openvpn(windscribe)[5618]: TUN/TAP device tun0 opened
Fri Jul  7 00:02:13 2017 daemon.notice openvpn(windscribe)[5618]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jul  7 00:02:13 2017 daemon.notice openvpn(windscribe)[5618]: /sbin/ifconfig tun0 10.110.34.41 netmask 255.255.254.0 mtu 1500 broadcast 10.110.35.255
Fri Jul  7 00:02:13 2017 daemon.notice openvpn(windscribe)[5618]: Initialization Sequence Completed

连接上服务器之后可以看看 OpenVPN tun 设备路由信息：

[root@PandoraBox:/root]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.110.34.1     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.58.71.1      0.0.0.0         UG    0      0        0 eth0.2
10.58.71.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
10.110.34.0     0.0.0.0         255.255.254.0   U     0      0        0 tun0
103.10.197.3    10.58.71.1      255.255.255.255 UGH   0      0        0 eth0.2
128.0.0.0       10.110.34.1     128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

dnsmasq 配置修改

与之前使用的 Shadowsocks 通过 ipset 自动分流类似，我们首先需要在 OpenWRT 上安装 dnsmasq-full 和 ipset 包。

基本原理也很简单，OpenWRT 上的 dnsmasq 服务器将 gfwlist 中的域名通过 OpenVPN 解析防止域名污染并将解析结果添加到 ipset，然后设置 ipset 中的所有 IP 地址都走 OpenVPN 翻墙，其它地址仍然走默认的宽带线路。

dnsmasq 使用 gfwlist 和 gfwlist 自动更新的方法可以参考我之前写的 newifi mini路由器OpenWRT初步体验文章。

我的服务器上基于 gfwlist 自动生成的 dnsmasq 配置文件地址没有变：

https://zohead.com/downloads/dnsmasq.tar.gz

只是自动更新 gfwlist 的 crontab 配置文件要修改一下了，因为上面的 dnsmasq 配置文件是为 Shadowsocks 本地转发解析域名准备的，这里换成 Google 提供的 8.8.8.8 DNS 解析服务器：

[root@PandoraBox:/root]#cat /etc/crontabs/root
10 5 * * * curl -k -o /tmp/dnsmasq.tar.gz https://zohead.com/downloads/dnsmasq.tar.gz && tar -C /tmp -xzf /tmp/dnsmasq.tar.gz && sed -i 's/127\.0\.0\.1#5353$/8.8.8.8/g' /tmp/dnsmasq_list.conf && cat /tmp/dnsmasq_list.conf > /etc/dnsmasq.d/dnsmasq_list.conf && rm -f /tmp/dnsmasq.tar.gz /tmp/dnsmasq_list.conf

配置 ipset 自动分流

首先修改 /etc/iproute2/rt_tables 配置文件，为 OpenVPN 专门增加一个名字为 gfwtable 的路由表（数字不和现有的表重复即可）：

99	gfwtable

需要注意的是我们可以从上面的 OpenVPN tun 设备路由信息中看到 OpenVPN 客户端连接上服务器之后自动添加了默认路由，而为了使默认流量都走宽带线路，需要修改 OpenVPN 配置文件禁用默认路由：

route-nopull

编辑 /etc/firewall.user 文件增加自定义的防火墙规则：

[root@PandoraBox:/root]# cat /etc/firewall.user
ipset -N gfwlist iphash
iptables -t mangle -N fwmark
iptables -t mangle -C OUTPUT -j fwmark || iptables -t mangle -A OUTPUT -j fwmark
iptables -t mangle -C PREROUTING -j fwmark || iptables -t mangle -A PREROUTING -j fwmark

分别简单解释一下：

第一行增加新的 iphash 类型的名为 gfwlist 的 ipset；
第二行在 iptables 的 mangle 表中新增 fwmark 链；
第三和第四行分别在 iptables 的 mangle 表的 OUTPUT 和 PREROUTING 链中增加 fwmark target，为了避免重复，增加之前都用了 iptables 命令判断原有规则是否已经存在；
后面三条规则有些 OpenWRT 系统里已经自带了，这里为了保险还是加上了。

接着还要再修改 Windscribe OpenVPN 配置文件，增加 VPN 的启动和停止脚本设置，因为我们要在脚本中添加 / 删除路由和 iptables 规则：

script-security 2
up /etc/openvpn/openvpn-up.sh
down /etc/openvpn/openvpn-down.sh

当然别忘了给 OpenVPN 启动和停止脚本增加执行权限：

[root@PandoraBox:/root]#chmod +x /etc/openvpn/openvpn-up.sh /etc/openvpn/openvpn-down.sh

OpenVPN 调用启动和停止脚本的参数格式会区分 tun 和 tap 设备，对于 tun 设备脚本调用参数是这样的：

cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ]

tap 设备则是：

cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ]

这里我们只需要关心第一个 tun /tap 设备名参数，我的 OpenVPN 启动脚本如下：

[root@PandoraBox:/root]#cat /etc/openvpn/openvpn-up.sh
#!/bin/sh
ip route add 8.8.8.8 dev $1
iptables -t mangle -A fwmark -m set --match-set gfwlist dst -j MARK --set-mark 0xffff
ip rule add fwmark 0xffff table gfwtable
ip route add default dev $1 table gfwtable
iptables -I FORWARD -o $1 -j ACCEPT
iptables -t nat -I POSTROUTING -o $1 -j MASQUERADE

同样简单说明一下：

首先将 8.8.8.8 DNS 解析服务器设置为从 OpenVPN 走防止域名污染；
使用 iptables mangle 表中的 fwmark 链为所有目标为 gfwlist ipset 中 IP 地址的数据包打标记，这里标记号用的是 0xffff；
所有标记号为 0xffff 的数据包都使用上面新增的 gfwtable 路由表；
gfwtable 路由表固定使用 OpenVPN 线路；
最后两条 iptables 规则也非常重要，允许路由器下的其它设备访问被封锁域名时走 OpenVPN 线路。

类似的 OpenVPN 停止脚本就比较简单了：

[root@PandoraBox:/root]#cat /etc/openvpn/openvpn-down.sh
#!/bin/sh
ip rule del table gfwtable
iptables -t mangle -D fwmark -m set --match-set gfwlist dst -j MARK --set-mark 0xffff
iptables -D FORWARD -o $1 -j ACCEPT
iptables -t nat -D POSTROUTING -o $1 -j MASQUERADE

都是清理启动脚本中增加的规则，ip route 项会在 tun 设备停止时自动删除，不需要手工进行清理了。

总结

经过这番对 OpenWRT 的配置折腾，现在住处的手机和电脑就都能通过 Windscribe OpenVPN 自动翻墙了。

最后贴上我的 newifi mini 路由器上的 Windscribe 完整 OpenVPN 配置文件给大家参考，由于文件比较长我放到 Pastebin 上了，最后祝大家炎炎夏日也能玩的开心：

http://pastebin.com/raw.php?i=TWbaMXdg

使用OpenVPN连接Windscribe免费VPN

Uranus Zhou — Fri, 07 Jul 2017 16:59:16 +0000

前言

最近换了住处之后，我还是没想到平时上网的宽带问题会成为一大痛点：现在住的地方基本上只能办理南京的广电宽带。广电宽带不但有着臭名昭著的速度慢游戏卡以及墙中墙问题，而且由于其 IP 地址资源有限，访问一些网站经常出现 IP 全国各地乱飞的情况，最要命的是其出国线路与我之前用的移动宽带完全没法比。

我观察到的南京广电宽带基本出国都是走联通线路，使用的是内蒙古包头之类的奇葩 IP 地址。之前在住处用于翻墙的 AlphaRacks VPS 和 Arukas 容器搭建的 Shadowsocks 服务器现在基本都处于不可用的状态，Google 搜索勉强能打开，Gmail 经常卡的不要不要的，YouTube 视频则基本不用想了。

更恶心的是广电宽带还直接屏蔽了 ICMP ping 外网的请求，只能 ping 广电内网的地址，至于普通的 traceroute 路由跟踪就更别想了。

下面贴出来的是我在 Linux 下使用专用的 TCP 路由跟踪 tcptraceroute 命令看到的惨不忍睹的结果，目的地址是移动宽带下用的无比顺畅的日本免费 Arukas 容器：

(trusty)zzm@localhost:~$ tcptraceroute -n 153.125.238.173 31626
Selected device wlan0, address 192.168.1.243, port 50713 for outgoing packets
Tracing the path to 153.125.238.173 on TCP port 31626, 30 hops max
 1  192.168.1.1  1.321 ms  1.567 ms  3.853 ms
 2  10.58.71.1  9.688 ms  14.964 ms  11.497 ms
 3  192.168.104.57  8.138 ms  20.722 ms  9.597 ms
 4  111.208.1.141  10.785 ms  11.364 ms  8.861 ms
 5  111.208.1.190  9.602 ms  10.524 ms  11.136 ms
 6  192.168.3.225  8.822 ms  9.481 ms  8.833 ms
 7  * * *
 8  172.16.116.13  70.035 ms  71.014 ms  68.664 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Destination not reached

由于我平常也使用 Chromebook 设备，特别依赖 Google 服务，Gmail 自不必说，经常要用 Google Drive 同步文件，另外也使用 Google Photos 备份照片，这样必须无法忍受需要找其它翻墙方案。

关于 Windscribe VPN

Windscribe 还是从我一个同事那里了解到的免费 VPN 服务，默认提供每个月 10GB 的流量，免费账户也有多国服务器可选，通过代金券可以增加到每月 50GB 或者 60GB。

需要的朋友可以通过下面的链接注册（没错，带了我的推荐小尾巴 ^_^），需要注意 Windscribe 网站必须翻墙才能打开：

https://windscribe.com/?friend=uxavdz64

Windscribe 的付费账户则是无限流量每月 $7.50 美元起，最近他们在搞 Lobster Lover 优惠活动，现在付费账户限时 3 折促销每年 $29.99 美元，有需要的朋友可以注册之后用 Lobster Lover 链接优惠升级哦。

账户注册完成之后登录，在 My Account 页面中点击 Claim Voucher 按钮输入代金券代码：

SOS60GBS，流量增加到每个月 60 GB，暂不确定什么时候过期；
50GBFREE，流量增加到每个月 50 GB。

Windscribe 提供了 Windows、Mac OS X、iPhone 下的客户端，而且还有官方的 Chrome、Firefox、Opera 浏览器下的 VPN 扩展程序，客户端下载链接在此：

https://chn.windscribe.com/download

从下载页面可以看到 Linux、Android 客户端都只有收费账户才支持，而且 Windscribe 并没有直接提供 Linux 和 Android 下的官方客户端，而是通过 OpenVPN、IKEv2、SOCKS5 等配置文件的方式让用户使用其它工具来连接 Windscribe VPN 服务器。

OpenVPN 连接 Windscribe

如此看来 Windscribe 是直接支持以 OpenVPN 方式来连接的，当然收费账户可以从下面的链接直接下载 OpenVPN 配置文件和证书：

https://chn.windscribe.com/getconfig/openvpn

虽然免费账户无法下载 OpenVPN 配置，但我估计 Windows 等系统下的客户端很有可能还是以 OpenVPN 方式实现的，马上下载安装 Windows 客户端来确认。

客户端安装的时候会自动提示安装 OpenVPN 的 TAP 驱动，完成之后使用 Windscribe 账户登录，默认会选择离我们最近的香港服务器。连接成功之后就能在进程列表看到 Windscribe 的 windscribeopenvpn.exe 程序，而且在命令行参数中还能看到 OpenVPN 配置文件路径：

"C:\Program Files (x86)\Windscribe\windscribeopenvpn.exe" --config "C:/Users/xxx/AppData/Local/Windscribe/Windscribe/config.ovpn" --management 127.0.0.1 57593 --management-query-passwords --management-hold

首先从下面的路径把 OpenVPN 配置文件拷贝出来：

C:/Users/xxx/AppData/Local/Windscribe/Windscribe/config.ovpn

配置文件内容大概是这样的：

client
dev tun

nobind
auth-user-pass
reneg-sec 432000
resolv-retry infinite

auth SHA512
cipher AES-256-CBC
keysize 256
comp-lzo
verb 2
mute-replay-warnings
ns-cert-type server
persist-key
persist-tun

key-direction 1

-----BEGIN CERTIFICATE-----
xxxxxx
-----END CERTIFICATE-----


-----BEGIN OpenVPN Static key V1-----
xxxxxx
-----END OpenVPN Static key V1-----

block-outside-dns

remote 103.10.197.3
port 443
proto udp

中间的 CA 证书和 TLS 认证 key 太长就没有全部贴出来了，remote 明显就是 Windscribe OpenVPN 服务器的地址，这里的 103.10.197.3 就是 Windscribe 的香港服务器。

现在剩下的问题就是 OpenVPN 的登录用户名和密码了，Windscribe 的 Linux 客户端说明中明确提醒用户需要注意的就是 OpenVPN 用户名和密码并不是 Windscribe 账户名和密码。

Windscribe 的 Windows 客户端里并没有直接提供用户名和密码，而且 Windscribe 网站上也只有付费账户才能得到，但这并不妨碍我们从 Windscribe 客户端的日志文件中找出端倪。

打开 Windscribe 客户端的日志文件：

C:\Users\xxx\AppData\Local\Windscribe\Windscribe\log.txt

不出意外的话你应该能在其中找到类似下面的输出：

[0607 03:18     36.573] [basic]	 state = CONNECT_BUTTON_CONNECTING
[0607 03:18     36.574] [basic]	 radiusUsername:  "nocwat_xxx"
[0607 03:18     36.574] [basic]	 radiusPassword:  "pppppp"
[0607 03:18     36.574] [basic]	 Connecting to "最佳位置"
[0607 03:18     36.574] [connection]	 Use latest successfully connection protocol: "UDP"
[0607 03:18     36.574] [connection]	 Connection settings: automatic
[0607 03:18     36.574] [connection]	 Location nodes: "node1 = {ip1 = 103.10.197.2, ip2 = 103.10.197.3, ip3 = 103.10.197.4}; "
[0607 03:18     36.575] [connection]	 OVPN-config path: "C:/Users/xxx/AppData/Local/Windscribe/Windscribe/config.ovpn"
[0607 03:18     36.575] [connection]	 Connecting to IP: "103.10.197.3"  protocol: "UDP"  port: 443

上面日志里的 radiusUsername 和 radiusPassword 就是 Windscribe 的 OpenVPN 服务器登录用户名和密码了。

接着就是打开 OpenVPN 软件使用刚才拷贝出来的 config.ovpn 配置文件，然后用上面的 OpenVPN 用户名和密码登录了，我的免费账户使用这种绕过 Windscribe 官方客户端的方式登录在测试中并没有发现什么问题。

Windscribe 服务器列表

到这里你应该能使用泛用型 OpenVPN 客户端来连接 Windscribe VPN 了，只是 Windscribe 多个地区的 VPN 服务器地址稍微麻烦点，毕竟使用过程中总会遇到某些地区的服务器比较慢需要切换的。

不过还好网上已经有人整理好了 Windscribe 的各地区 VPN 服务器地址了，大家直接从下面的地址下载 UDP 或者 TCP 协议的各地区 OpenVPN 配置文件：

Windscribe-OVPN-UDP.zip
Windscribe-OVPN-TCP.zip

解压缩之后使用其中某个地区的 OpenVPN 配置文件即可，登录时仍然使用前面日志文件中找到的用户名和密码。

当然后面很可能会碰到配置文件中的服务器地址不正确或者 Windscribe 修改了证书之类的情况，不过大家还是可以从 Windscribe 客户端的服务日志中找到正确的服务器地址，例如：

[04-07 12:11:06]	Service started
[04-07 12:15:14]	AA_COMMAND_FIREWALL_CHANGE, AllowLocalTraffic=1, Ips=38.95.108.xxx;xxxxxx;104.18.56.xxx
[04-07 12:15:14]	AA_COMMAND_FIREWALL_IPV6_ENABLE
[04-07 12:15:14]	Error 13
[04-07 12:15:14]	AA_COMMAND_EXECUTE, blocking=0, cmd="C:\Program Files (x86)\Windscribe\windscribeopenvpn.exe" --config "C:/Users/xxx/AppData/Local/Windscribe/Windscribe/config.ovpn" --management 127.0.0.1 57593 --management-query-passwords --management-hold

上面日志输出中的 Ips（并没有全部列出来）就是客户端获取到的所有 Windscribe VPN 服务器的地址了。

移动宽带丧心病狂的流量劫持

Uranus Zhou — Tue, 30 May 2017 04:26:42 +0000

流量劫持情况

最近我发现在住处的江苏移动宽带网络环境下用手机浏览一些 HTTP 网站很容易出现和网站内容明显不符的抢红包广告，有时候页面会显示错乱，而在 PC 端打开同样的网址又没有问题。这种情况只在 HTTP 网站上碰到过，初步判断这就是移动宽带一贯使用的流量劫持把戏。

被劫持的网页在手机端显示起来是这样的：

页面中间的浮标和页面下方的开红包图标都明显不是原始网站投放的广告。这种劫持行为一般在手机浏览器上刷新一下就暂时没有了，但很多情况下会碰到运营商插入的广告导致移动端网页布局出现异常，无法正常使用。

劫持情况分析

由于直接在 PC 端打开被劫持的网址很可能不会出现被插入广告的情况，模拟手机浏览器 user agent 也要碰运气才能出现，因此我直接使用 Android Chrome 浏览器的远程调试功能来进行分析。

打开 Android 的 USB 调试功能，通过数据线连接电脑，在 PC 端 Chrome 浏览器上进入：chrome://inspect/#devices 就能看到连接上的 Android 手机上 Chrome 浏览器打开的标签页，为了方便调试和安利给大家，我使用的是直接基于 Chrome 的 Chromebook 设备：

点击标签页下方的 inspect 按钮就可以远程调试了。

在 Elements 调试界面可以看到运营商在网页结束之前插入了两个 div：tuia-fubiao 和 tuia-customer，更恶心的是下面还加了一个隐藏的 iframe。

不过看了被劫持之后实际的网页源代码你才能感受到移动宽带的丧心病狂，首先网页标签之后就插入了奇奇怪怪的广告代码：

移动宽带在的网站原有 script 脚本中间还硬插了一段：

连 CSS 也别想幸免，结束也插入了一段，这里的 CSS 代码太长我就不全部贴出来了：



......

至于结束之前插入的广告代码是这样的：

面对这样被改的面目全非的网页源代码，我简直是无语到极点。移动宽带为了插广告使用这种下作的劫持方式，也难怪手机浏览器上很容易碰到被劫持后一些移动版网站显示错乱的问题了。

另一种流量劫持

另外使用移动宽带在手机端上网还可能碰到一种比较常见和看起来稍微「良心」一点的劫持方式。

这是我用 Android Chrome 浏览器访问少数派网站时碰到的劫持情况，被劫持的网页代码变成这样：

这是最常见的 iframe 劫持方式，外面的广告代码套上源网站，只能说好歹还没有直接魔改源网站的代码，另外插入的广告代码同样来自 112.4.23.122 这个 IP 地址。

查询之后发现该 IP 地址是：江苏省南京市全省共用出口移动，很明显这些流量劫持行为是南京移动宽带内部人员为利益驱使而做的。

后续处理

发现移动宽带的流量劫持行为之后，我首先与南京移动联系进行了投诉，不出所料移动客服又是一番先坚决不承认然后让提供技术证明的节奏，直到我威胁要投诉到工信部，移动才表态愿意处理此问题。

投诉之后的十几天手机访问一些 HTTP 的网站确实没见到广告劫持了，然而好景不长，前些天又在手机上看到了插入的广告，无奈我先在路由器上直接屏蔽了劫持代码中的 IP 地址和网站域名，而且最近马上要搬家换住处了，可能也不会继续用移动宽带了，因此就没有兴趣继续跟进此事咯。

当然目前最好的应对方式还是希望众多网站能尽快切换到全站 HTTPS 了，文章开头截图里被劫持的伯乐在线网站仍然在用 HTTP，国内移动互联网流量的大头微信公众号也没有切换到 HTTPS（我也碰到过公众号文章被劫持插入代码的情况）。

比较欣慰的是我写这篇文章的时候，少数派网站看起来也已经使用 HTTPS 了，最后祝大家儿童节快乐 ^_^。

小内存OpenVZ VPS使用UML开启BBR

Uranus Zhou — Mon, 06 Mar 2017 18:39:55 +0000

前言

Bottleneck Bandwidth and RTT（BBR）是 Google 最近提交到 Linux 4.9 版本内核的新 TCP 拥塞控制算法，BBR 相对于 Linux 中已经用了好多年的默认 CUBIC 算法的主要改进是在有一定丢包率的网络链路上充分利用带宽，另外也能有效降低延迟。这对于很多使用美帝 VPS + Shadowsocks 爬墙方案的人来说应该还是比较有用的，目前从一些更新了内核开启 BBR 的 KVM VPS 用户的反馈来看效果也还是不错的。

我目前使用的爬墙服务器是 AlphaRacks 的低配 OpenVZ VPS，内存只有 96 MB，到国内的线路质量倒还凑合，OpenVZ 虽然没办法直接升级 kernel ，但看到 AlphaRacks 控制面板里能开启 TUN/TAP，那可以考虑捣鼓使用 User-mode Linux（UML）来开启 BBR 了。

User-mode Linux 和 QEMU 这种虚拟机稍微有点类似，但 UML 是直接将 Linux 内核编译成可执行的 ELF 应用层程序，这样可以直接在普通 Linux 环境中运行及调试其它版本 Linux 内核的功能，有关 UML 的详细信息请参考其官方网站。

提示

不想自己编译 UML 内核和构建 UML rootfs 的朋友可以直接拉到「使用 UML Shadowsocks 系统」这部分哦。

编译 User-mode Linux 内核

准备编译环境

我是直接在 Windows 10 RS2 64 位系统上编译 UML 内核的，使用 Win10 自带的 Bash on Ubuntu 14.04 环境编译还是非常方便的，而且编译速度相比使用虚拟机也是快了很多。

首先安装编译需要的软件包：

备注

由于我使用的 OpenVZ VPS 系统是 32 位的，所以这里安装 libc-dev 和 libvdeplug-dev 开发包时都指定了使用 32 位版本；如果你需要编译 64 位版本的 UML 内核，那把下面的 -i386 去掉即可。

zzm@ZZM-P238:~$ sudo apt-get install build-essential libncurses5-dev libc6-dev-i386 libvdeplug-dev-i386

这里安装 libvdeplug-dev 开发包是为了支持 UML 的 Virtual Distributed Ethernet（VDE）模式网卡设备，VDE 主要是为了让 UML 的网络功能在类似 Docker 这种连 TUN/TAP 都不支持的系统上也能工作起来。

接着可以下载最新 Linux 4.10.1 版本内核源代码，并解压缩准备配置内核选项，4.10.1 版本源代码解压之后不到 800 MB。

提示

如果像我一样直接在 Win10 Bash 环境中编译，那么最好将内核源代码解压到 Win10 Bash 的 VolFs 文件系统中（也就是 Ubuntu rootfs 目录，一般直接 cd 到 HOME 主目录即可）。

UML 内核配置

如果使用默认的 UML 内核配置是比较简单的，直接下面两步即可，第二步内核配置界面里可以手工开启 BBR 功能：

zzm@ZZM-P238:~/linux-4.10.1$ cp arch/um/configs/i386_defconfig .config
zzm@ZZM-P238:~/linux-4.10.1$ make menuconfig ARCH=um

不过为了能编译出体积最小又能满足 BBR 爬墙需要的 kernel，我还是使用自己修改的最小配置，首先将下面的内容保存为 mini.config 文件（如果需要编译 64 位 kernel，那直接把开头的 CONFIG_64BIT=n 这一行去掉即可）：

zzm@ZZM-P238:~/linux-4.10.1$ cat mini.config
CONFIG_64BIT=n
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=n
CONFIG_HOSTFS=y
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_KERNEL_STACK_ORDER=1
CONFIG_SWAP=n
CONFIG_SYSVIPC=y
CONFIG_EXPERT=n
CONFIG_EMBEDDED=n
CONFIG_SLUB_DEBUG=n
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_BLK_DEV_BSG=n
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_UBD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=n
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_NETDEVICES=n
CONFIG_STDERR_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_TMPFS=y
CONFIG_SYSFS=y
CONFIG_SCHED_DEBUG=n
CONFIG_NET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_BBR=y
CONFIG_DEFAULT_BBR=y
CONFIG_DEFAULT_TCP_CONG="bbr"
CONFIG_IPV6=n
CONFIG_SYN_COOKIES=y
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_QFQ=y
CONFIG_NET_SCH_CODEL=y
CONFIG_NET_SCH_FQ_CODEL=y
CONFIG_NET_SCH_FQ=y
CONFIG_NET_SCH_FIFO=y
CONFIG_UML_NET=y
CONFIG_UML_NET_TUNTAP=y
CONFIG_UML_NET_VDE=y
CONFIG_DEBUG_KERNEL=n
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1

简单说明一下上面的内核配置选项：

启用了 UML 的 hostfs 及 mconsole 等很实用的功能；
支持 UML 的 ubd 块设备，也开启了 loop 设备支持，去掉了 ramdisk 等没什么用的其它设备支持；
支持 proc、sysfs、tmpfs 等虚拟文件系统，真实的文件系统只保留了 ext2 支持，需要 ext3 或者 ext4 支持的朋友请自行修改；
开启 BBR 并设置为默认拥塞控制算法，另外需要为 BBR 启用 Fair Queue 包调度器；
去掉了 IPv6 支持，去掉了所有的网卡设备驱动；
去掉了几乎所有的内核调试信息。

然后使用 mini.config 生成新的内核配置文件：

zzm@ZZM-P238:~/linux-4.10.1$ make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.config

编译内核

内核选项配置完毕之后，编译就非常简单了：

zzm@ZZM-P238:~/linux-4.10.1$ make ARCH=um vmlinux -j4

这里我开启了 4 个并发编译（make 的 -j4 参数）支持，UML 的 vmlinux 可执行程序在我的笔记本上不到 4 分钟就编译完成了，最终编译出来的 vmlinux 文件大小大概为 3 - 4 MB。

你可以试着运行编译出来的 vmlinux 可执行程序查看编译时使用的内核配置：

[root@localhost ~]# ./vmlinux --showconfig

准备 UML rootfs

准备 rootfs 和 shadowsocks-libev

既然 UML 内核我都是按最小化编译的，那运行的 rootfs 自然不能用像 Ubuntu、CentOS 那种「庞大」的系统了，这里我直接使用最小化的 busybox rootfs + Shadowsocks 服务端程序和运行库的方式，除了 busybox 基础环境和 Shadowsocks 服务端程序基本没有添加任何其它东西。

最终我将 UML vmlinux 内核文件和 rootfs 目录一起压缩打包起来大小也不过才 3 MB，这样能非常方便地上传到 VPS 上和分享给其他人。当然缺点就是如果需要安装其它的软件那只能手工拷贝到 rootfs 目录中了。

具体 busybox rootfs 的制作方法这里我就不做详细说明了，感兴趣的朋友可以参考相关的文档了解一下，我分别制作了 32 位和 64 位的 busybox rootfs 目录。

另外为了减少 UML 系统的程序依赖和内存占用，Shadowsocks 服务端我选择的是 shadowsocks-libev，这里我也分别编译了最新 3.0.3 版本 32 位和 64 位的服务端程序。

32 位 shadowsocks-libev 我是在 32 位 Ubuntu 14.04 系统下编译的，依赖的动态库也是使用的 Ubuntu 14.04 自带的库文件；64 位 shadowsocks-libev 则是在 64 位 CentOS 6 系统下编译的，所以 64 位运行库版本和 32 位的不同。你问我为什么不用同一个系统？因为我刚好有这两个系统的 VPS 能用来编译，实在是懒的换了 ^_^。

测试 UML rootfs

由于 OpenVZ 系统内核不支持 loop 设备，不能挂载文件系统映像进行修改，这里我直接使用 UML 的 hostfs 将 OpenVZ 主机系统的一个目录设为 UML 系统的 rootfs。

现在 UML hostfs 并没有某些网友说的存在只读的限制，而且相比使用 loop 设备或者 ubd 文件系统这种方式，hostfs 并不需要预先产生一个很大的文件，主机也能直接修改 UML rootfs 目录内容，UML 内核也根本不需要支持 ext3、ext4 这种真实的文件系统，综合比较下来实在是没有什么理由不用 hostfs。

首先安装 UML 工具 uml-utilities 软件包，后面的 tunctl 和 uml_mconsole 等命令会用到：

root@zohead:~# apt-get install uml-utilities

接着可以配置 OpenVZ 系统上的 TUN/TAP 虚拟网卡和开启端口转发：

root@zohead:~# tunctl -u root
Set 'tap0' persistent and owned by uid 0
root@zohead:~# ifconfig tap0 192.168.0.3 up
root@zohead:~# echo 1 > /proc/sys/net/ipv4/ip_forward
root@zohead:~# iptables -t nat -I POSTROUTING -o venet0 -j MASQUERADE
root@zohead:~# iptables -t nat -A PREROUTING -i venet0 -p tcp --dport 9443 -j DNAT --to-destination 192.168.0.4
root@zohead:~# iptables -t nat -A PREROUTING -i venet0 -p udp --dport 9443 -j DNAT --to-destination 192.168.0.4

备注

上面的命令中假设 TUN/TAP 虚拟网卡 IP 地址为 192.168.0.3（可以自行修改），UML 系统网卡 IP 地址为 192.168.0.4（需要和 TUN/TAP 虚拟网卡地址在同一网段），只将 OpenVZ 主机系统上 9443 端口的 TCP 和 UDP 数据转发到 UML 系统网卡上。

最后是启动 UML 系统的例子：

root@zohead:~# ./vmlinux-i686 umid=shadowsocks root=/dev/root rootfstype=hostfs rootflags=/root/umlfs-i686 rw mem=48M init=/sbin/init eth0=tuntap,tap0

简单说明一下 UML vmlinux 程序的参数：

umid 参数指定 UML 系统 ID，建议每个 UML 系统都使用的固定的 ID，不然每次运行都会在 ~/.uml 目录下产生新的临时目录；
rootflags 参数指定 UML rootfs 路径，这里必须使用绝对路径；
mem 参数指定 UML 系统的内存大小，经过我的测试，只运行 shadowsocks-libev 服务端的话就算分配 32 MB 内存看起来也没什么压力；
init 参数指定 UML 系统的 init 进程，不建议修改；
eth0=tuntap,tap0 则是指定 UML 的 tuntap 模式网卡，使用 OpenVZ 主机系统的 tap0 虚拟网卡设备。

使用 UML Shadowsocks 系统

uml-linux.sh 脚本

为了使用起来方便，我把启动 UML 系统和设置端口转发的操作写成了一个 uml-linux.sh 脚本，这样 OpenVZ 系统启动之后可以根据配置自动运行并配置端口转发：

#!/bin/sh
UML_ID="shadowsocks"
TAP_DEV="tap0"
ROUTER_DEV="venet0"
TAP_ADDR="192.168.0.3"
UML_ADDR="192.168.0.4"
REV_TCP_PORTS=""
REV_UDP_PORTS=""
FWD_TCP_PORTS="9443"
FWD_UDP_PORTS="9443"

DIR="$( cd "$( dirname "$0" )" && pwd )"

[ ! -d /sys/class/net/$TAP_DEV ] && tunctl -t $TAP_DEV
ifconfig $TAP_DEV $TAP_ADDR up

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -I POSTROUTING -o $ROUTER_DEV -j MASQUERADE

for i in $REV_TCP_PORTS; do
	if [ "x$i" = "x*" ]; then
		P_TMP=""
	else
		P_TMP="--dport $i "
	fi
	iptables -t nat -A PREROUTING -p tcp $P_TMP-j RETURN
done
for i in $REV_UDP_PORTS; do
	if [ "x$i" = "x*" ]; then
		P_TMP=""
	else
		P_TMP="--dport $i "
	fi
	iptables -t nat -A PREROUTING -p udp $P_TMP-j RETURN
done

for i in $FWD_TCP_PORTS; do
	if [ "x$i" = "x*" ]; then
		P_TMP=""
	else
		P_TMP="--dport $i "
	fi
	iptables -t nat -A PREROUTING -i $ROUTER_DEV -p tcp $P_TMP-j DNAT --to-destination $UML_ADDR
done
for i in $FWD_UDP_PORTS; do
	if [ "x$i" = "x*" ]; then
		P_TMP=""
	else
		P_TMP="--dport $i "
	fi
	iptables -t nat -A PREROUTING -i $ROUTER_DEV -p udp $P_TMP-j DNAT --to-destination $UML_ADDR
done

nohup $DIR/vmlinux-i686 umid=$UML_ID root=/dev/root rootfstype=hostfs rootflags=$DIR/umlfs-i686 rw mem=48M init=/sbin/init con=pts eth0=tuntap,$TAP_DEV,,$UML_ADDR &

一般只要修改脚本最开始的几行配置即可（最后一行 vmlinux 程序和 UML rootfs 路径默认使用脚本所在路径，如果不同请自行修改）：

TAP_ADDR 为 TUN/TAP 虚拟网卡地址，UML_ADDR 为 UML 系统内网卡地址；
REV_TCP_PORTS 和 REV_UDP_PORTS 分别指定 OpenVZ 主机系统需要保留哪些 TCP 和 UDP 端口不转发到 UML 系统（多个以空格隔开），一般如果 UML 系统使用固定的一些端口，那么默认留空即可；
FWD_TCP_PORTS 和 FWD_UDP_PORTS 分别指定哪些 TCP 和 UDP 端口需要转发到 UML 系统（默认只写了一个 9443，实际如果需要多个则以空格隔开），如果需要指定端口范围也可以写成 15000:20000，如果需要所有端口都转发到 UML 系统那可以直接写成 *（此时 REV_TCP_PORTS 一般最少要留一个端口用于 SSH 远程登录）；
需要分配给 UML 系统的内存大小请自行修改 vmlinux 的 mem 参数。

UML Shadowsocks 系统配置

另外 UML 系统内部的网卡地址配置及启动 shadowsocks-libev 服务端的操作都在 /etc/rc.local 脚本中：

#!/bin/sh
if [ -d /sys/class/net/eth0 ]; then
	ifconfig eth0 192.168.0.4 up
	route add default gw 192.168.0.3 dev eth0
	sleep 2
fi

SS_DNS=""

[ -f /etc/default/pdnsd ] && . /etc/default/pdnsd

# start local DNS server if needed
if [ "x$START_DAEMON" = "xyes" -o "x$START_DAEMON" = "xYES" ]; then
	pdnsd -d
	[ $? -eq 0 ] && SS_DNS="-d 127.0.0.1 "
fi

for i in `ls /etc/shadowsocks-libev/*.json 2>/dev/null`; do
	SS_NAME=`basename $i .json 2>/dev/null`
	start-stop-daemon -n shadowsocks-$SS_NAME -x ss-server -b -S -- -c $i -u $SS_DNS--fast-open
done

exit 0

简单说明一下：

这里的 192.168.0.4 网卡 IP 地址就对应上面的 UML_ADDR，192.168.0.3 网关地址就是 TAP_ADDR，因此如果上面脚本中的地址修改了，那么 UML rootfs 的 /etc/rc.local 中的地址也需要修改；
你可以将 shadowsocks-libev 配置文件放到 /etc/shadowsocks-libev 目录中，此脚本会自动遍历并一一启动 ss-server 服务器，同时默认也开启了 TCP Fast Open 和 UDP 转发；
另外 rootfs 里集成了 pdnsd DNS 服务器，如果需要实现 DNS 缓存加速或者 UML 系统的 UDP DNS 解析存在问题，都可以启用 pdnsd 本地 DNS 服务器。

配置修改完成之后，运行 uml-linux.sh 脚本就会在后台启动 UML 系统，并根据需要自动启动 shadowsocks-libev 服务器。

控制 UML 系统

如果你需要登录到 UML 系统，可以先用 uml_mconsole 命令得到 UML 系统分配到的虚拟终端（第二个参数就是 UML 系统 ID）：

root@zohead:~# uml_mconsole shadowsocks config con0
OK pts:/dev/pts/2

然后使用 screen 命令就可以连接到该虚拟终端上（默认什么都不显示，需要按回车键终端才会出来）：

root@zohead:~# screen /dev/pts/2

如果想在 OpenVZ 主机系统里直接关闭整个 UML 系统，那也非常简单：

root@zohead:~# uml_mconsole shadowsocks halt

UML Shadowsocks 系统下载

为了方便大家使用，我把 32 位和 64 位的 UML 4.10.1 版本 vmlinux 内核程序及配置和 Shadowsocks 服务端 rootfs 目录、uml-linux.sh 脚本一起打包分享给大家。

32 位的 UML Shadowsocks 系统（百度网盘备用）：

https://zohead.com/downloads/uml-shadowsocks-i686.tar.xz
https://pan.baidu.com/s/1kVdoWcB

64 位的 UML Shadowsocks 系统：

https://zohead.com/downloads/uml-shadowsocks-x64.tar.xz
https://pan.baidu.com/s/1dFDta9N

将上面的文件下载到 VPS 某个目录并解压缩，修改 uml-linux.sh 文件中的转发端口，将 Shadowsocks 服务端配置文件放到 rootfs 的 /etc/shadowsocks-libev 目录，之后以 root 身份运行 uml-linux.sh 脚本即可。

提示

如果需要让 ShadowsocksR 服务器使用 TCP 等方式进行域名解析，可以修改 /etc/default/pdnsd 文件将其中的 START_DAEMON 改为 yes 来启用 pdnsd 本地 DNS 服务器。

UML ShadowsocksR 系统

考虑到某些网友的需要，我还生成了 32 和 64 位的 UML ShadowsocksR 系统，都是使用的最新支持混淆的 Python 版本 ShadowsocksR 服务器，有需要的朋友可以下载测试（百度网盘为备用下载地址）。

32 位的 UML ShadowsocksR 系统：

https://zohead.com/downloads/uml-shadowsocksr-i686.tar.xz
https://pan.baidu.com/s/1eSDrWye

64 位的 UML ShadowsocksR 系统：

https://zohead.com/downloads/uml-shadowsocksr-x64.tar.xz
https://pan.baidu.com/s/1o7F3qpc

ShadowsocksR 系统的 rootfs 只包含了基础 Python 环境和 ShadowsocksR 服务器程序，同样下载并解压缩，由于包含了 Python 环境，该 rootfs 解压缩之后接近 30 MB。

使用前可根据需要修改 uml-linux.sh 文件中的转发端口，将 ShadowsocksR 服务器 JSON 格式配置文件放到 rootfs 的 /etc/shadowsocks 目录，之后以 root 身份运行 uml-linux.sh 脚本即可（启用 pdnsd 本地 DNS 服务器的方法和上面的相同）。

UML 系统 BBR 效果

最后对比一下我的 AlphaRacks OpenVZ VPS 上启用 BBR 前后的对比速度，这里我就直接观看同一个 1080p 的 YouTube 视频来对比统计信息了。

在我的江苏移动宽带环境下，启用 BBR 之前 YouTube 视频连接速度一般只能跑到 1Mbps 左右：

而在使用 UML Shadowsocks 系统开启 BBR 之后能跑到 2Mbps，不过有的时候速度还是不太稳定：

UML 目前也是主要用于调试验证 Linux 内核功能的，总之 OpenVZ 使用 UML 开启 BBR 的实际使用效果还是需要长期观察测试的，本文也主要关注 UML 系统下使用 Shadowsocks 的问题，并没有考虑通用的情况，如果文章中有任何问题还请提出指正，祝大家玩的开心。

暂时迁移被爬虫扒得内存不足的VPS

Uranus Zhou — Sat, 11 Feb 2017 14:44:57 +0000

VPS 内存不足问题

最近一两个月我在查看 VPS 运行日志的时候，经常发现 kernel 日志中会有 Out of memory 内存不足报错，而且报错基本都是 php-fpm 引起的：

root@zoserver:~# cat /var/log/kern.log
Dec 15 20:11:43 zoserver kernel: [55751339.090508] Out of memory in UB 1253: OOM killed process 32239 (php-fpm) score 0 vm:56336kB, rss:29832kB, swap:0kB
Dec 15 20:11:56 zoserver kernel: [55751352.643620] Out of memory in UB 1253: OOM killed process 32238 (php-fpm) score 0 vm:55580kB, rss:29444kB, swap:0kB
Dec 15 20:11:57 zoserver kernel: [55751353.609602] Out of memory in UB 1253: OOM killed process 32242 (php-fpm) score 0 vm:56088kB, rss:29800kB, swap:0kB
Dec 15 20:12:23 zoserver kernel: [55751379.072308] Out of memory in UB 1253: OOM killed process 32240 (php-fpm) score 0 vm:55496kB, rss:29520kB, swap:0kB
Dec 15 20:12:45 zoserver kernel: [55751401.084746] Out of memory in UB 1253: OOM killed process 32225 (php-fpm) score 0 vm:55848kB, rss:29564kB, swap:0kB
Dec 15 20:13:22 zoserver kernel: [55751438.326072] Out of memory in UB 1253: OOM killed process 32266 (php-fpm) score 0 vm:56008kB, rss:29880kB, swap:0kB
Dec 15 20:13:36 zoserver kernel: [55751452.087637] Out of memory in UB 1253: OOM killed process 32278 (php-fpm) score 0 vm:55328kB, rss:29356kB, swap:0kB
Dec 15 20:13:37 zoserver kernel: [55751453.035146] Out of memory in UB 1253: OOM killed process 32241 (php-fpm) score 0 vm:55752kB, rss:29784kB, swap:0kB

从日志里可以看到每个 php-fpm 进程的 rss 内存占用都接近 30 MB，我之前就已经将 LNMP 环境里的 php-fpm.conf 配置文件中的 pm.max_children 改为 8，这样如果碰到同时请求数较多的情况，php-fpm 就可能会占用 240 MB 内存。再加上 MySQL、BTSync 等其它程序也要占用内存，我这个在 HighSpeedWeb 上购买的 256 MB 内存的 VPS 应该就撑不住了，出现 Out of memory 错误也就不足为怪了。

为了找到原因，我决定检查一下出现内存不足时候的 nginx 请求日志：

root@zoserver:~# more /home/wwwlogs/zohead.log
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/tcpkill-nfs/ HTTP/1.1" 200
13304 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/newifi-mini-openwrt/ HTTP/1.1" 200
18841 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/linux/ubuntu/ HTTP/1.1" 200
11921 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/phone/ HTTP/1.1" 200
12800 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/ HTTP/1.1" 200
14862 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/category/technology/android/ HTTP/1.1" 200
15127 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/zerotier-container/ HTTP/1.1" 200
16323 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/tag/bash/ HTTP/1.1" 200
11221 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/tag/ssh/ HTTP/1.1" 200
11266 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"

这就明显是一个不太友善的爬虫干的好事了，由于请求日志太多这里就不列出来了，统计之后可以发现这个 SMTBot 在十几秒钟的时间里请求了几百次，明显超出了 VPS 能处理的范围了。

另外我在检查日志之后还发现经常有各种初步练习用的爬虫也在不断访问 WordPress 博客数据，这种爬虫的特征就是使用各种不同的 User agent：

root@zoserver:~# more /home/wwwlogs/zohead.log
138.197.19.145 - - [17/Dec/2016:08:28:49 +0800] "GET /robots.txt HTTP/1.1" 200
145 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:00 +0800] "GET /wp-login.php HTTP/1.1" 200
2464 - "http://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:01 +0800] "GET /archives/category/technology/network-tech/https-ssl/ HTTP/1.1" 200
8604 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/category/travel/ HTTP/1.1" 502
166 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/tag/video/ HTTP/1.1" 200
11459 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /guestbook/ HTTP/1.1" 200
9962 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/tasker-shell/ HTTP/1.1" 200
13094 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/category/technology/ HTTP/1.1" 200
13717 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/tag/android/ HTTP/1.1" 200
13879 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/category/technology/android/ HTTP/1.1" 200
13842 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:05 +0800] "GET /archives/author/admin/ HTTP/1.1" 200
13716 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"

然而这些小爬虫发起请求来也是毫不手软，基本没有在多个请求之间加什么延时的。不过还好看起来爬虫还是读了 robots.txt 文件的，因此可以考虑在 robots.txt 和 nginx 配置里做一些限制。

防治措施

修改 robots.txt

首先把原来不太重视的 robots.txt 文件完善一下，增加了一些限制，大概如下：

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /*?replytocom=*
Crawl-delay: 30
Sitemap: https://zohead.com/sitemap.xml

禁止所有爬虫访问一些 WordPress 内部目录，增加了 Crawl-delay 参数，并设置为 30 秒，防止产生过多的请求。

修改 nginx 配置

由于并不是所有爬虫都会读取并遵守 robots 协议，特别是 Google 和百度这样的搜索巨头也明确表态不支持上面增加的 Crawl-delay 参数，为此还是需要修改 nginx 配置直接限制并发连接数：

root@zoserver:~# more /usr/local/nginx/conf/nginx.conf
http {
	limit_req_zone $anti_spider zone=anti_spider:60m rate=200r/m;
}

server {
	limit_req zone=anti_spider burst=5 nodelay;
	set $anti_spider $http_user_agent;
}

上面只是简单节选列出了 nginx 服务器配置的修改，使用 limit_req_zone 限制每分钟 200 个请求，最大并发为 5。

经过上面两步修改之后，VPS 日志里的内存不足错误看起来是减少了，但是好景不长，直到过几天我再去检查内核日志和 nginx 请求日志时发现来了一个臭名昭著的家伙，其频繁的请求仍然导致 VPS 出现 Out of memory 问题：

root@zoserver:~# more /home/wwwlogs/zohead.log
42.236.99.242 - - [09/Jan/2017:05:41:44 +0800] "GET /archives/tag/keepassdroid/?wpmp_switcher=mobile HTTP/1.1" 503
608 - "https://m.zohead.com/archives/tag/keepassdroid/?wpmp_switcher=mobile" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.178 - - [09/Jan/2017:05:41:44 +0800] "GET /archives/easymoney-to-feidee/?lang=en&replytocom=641replytocom=641replytocom=641replytocom=640replytocom=641replytocom=641replytocom=640replytocom=640&wpmp_switcher=desktop HTTP/1.1" 503
608 - "https://zohead.com/archives/easymoney-to-feidee/?lang=en&replytocom=641replytocom=641replytocom=641replytocom=640replytocom=641replytocom=641replytocom=640replytocom=640&wpmp_switcher=desktop" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.230 - - [09/Jan/2017:05:41:45 +0800] "GET / HTTP/1.1" 301
178 - "http://www.zohead.com/" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.194 - - [09/Jan/2017:05:41:47 +0800] "GET /archives/qiniu-https-tamper/?lang=en&replytocom=2190 HTTP/1.1" 200
12300 - "https://zohead.com/archives/qiniu-https-tamper/?lang=en&replytocom=2190" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.206 - - [09/Jan/2017:05:41:48 +0800] "GET /archives/category/technology/linux/page/3/?wpmp_switcher=true HTTP/1.1" 503  
608 - "https://m.zohead.com/archives/category/technology/linux/page/3/?wpmp_switcher=true" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
180.153.236.19 - - [09/Jan/2017:05:41:48 +0800] "GET /archives/category/technology/cplusplus/ HTTP/1.1" 503
608 - "https://m.zohead.com/archives/category/technology/cplusplus/" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.154 - - [09/Jan/2017:05:41:48 +0800] "GET /comments/feed/?lang=en HTTP/1.1" 503
608 - "http://zohead.com/comments/feed/?lang=en" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
180.153.236.165 - - [09/Jan/2017:05:41:49 +0800] "GET /archives/tag/start-stop-daemon/?lang=en&wpmp_switcher=mobile HTTP/1.1" 200
8502 - "http://zohead.com/archives/tag/start-stop-daemon/?lang=en&wpmp_switcher=mobile" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"

上面只是同一时段博客访问日志的很小一部分，360 搜索的 360Spider 爬虫在不断访问博客，而且看起来 360 服务器集群机器也是相当多，360 蜘蛛的 IP 地址列表可以在其官网查看：

https://www.so.com/help/spider_ip.html

经过分析日志我发现最要命的是 360 爬虫根本就没有读取 robots.txt 文件，这样根本谈不上让 Crawl-delay 之类的参数发挥作用。

迁移服务器

经过我差不多一个月的观察，现在 VPS 遇到的内存不足问题基本都是由 360 爬虫引起的，另外偶尔也有一些小爬虫不按规矩狂发请求。只是考虑到现在这个 256 MB 内存的 VPS 始终不是长久之计，因此还是想把博客迁移到其它服务器上。

首先看了看 HighSpeedWeb 现有的套餐，512 MB 内存以上的 OpenVZ 或 KVM 套餐现在价格也都不太便宜。一番参考之后我准备先将博客迁移到 IBM Bluemix 容器平台顶着，因为看起来 Bluemix 容器系统里能使用的突发内存量还是比较多的，而且毕竟目前 Bluemix 平台在我这几个月的使用感受来看除了计费不太清晰之外其它方面还算比较稳定的。

现在博客域名的 A 记录已经修改，你现在看到的页面就是运行在 Bluemix 容器上的了。另外最近碰到好几次 HTTP 的博客网站老是被运营商插入广告代码，于是我也直接禁用了 HTTP 支持，现在必须以 HTTPS 方式访问本博客了。这么一来只是略微可惜了原来 HighSpeedWeb 相当稳定的服务器了：

root@zoserver:~# uptime
 21:29:27 up 325 days,  6:16,  1 user,  load average: 0.00, 0.00, 0.00

HighSpeedWeb VPS 服务器已经稳定运行了将近一年时间了，基本上自从上次续费时不小心重启了一下服务器之后 DNSPod 的监控就没有再报过警了。因此这段时间如果 Bluemix 容器万一出什么幺蛾子还能尽快切换回 HighSpeedWeb，最后还是希望现在的 Bluemix 容器能尽量稳定运行了，祝大家元宵节玩的开心。