两年前把 Tailscale 装进越狱 Kindle 的人，大概都遇到过同一个尴尬：管理后台里，设备是绿的，SSH 也能连进去。可打开 KOReader，想访问自建的 Calibre 服务器，敲一个 100.x.y.z 的 Tailscale 地址，连不上。
问题不在 Tailscale，在 Kindle 的网络只能跑在用户态，没法把路由这件事交给系统内核。别人能看见你，你却连不出去——这套社区方案最近打了补丁，加上代理模式和部分机型能用的完整 TUN，才算把这两件事拉平。
三件新事，谁会用到
- Tailscale SSH 默认开启：不用再依赖 USBnetworking SSH 那套人尽皆知的默认用户名密码，谈不上“绝对更安全”，但至少堵上了一个最显眼的口子。
- 代理模式.KOReader 等应用把代理地址填成本机
127.0.0.1:1055（SOCKS5）或1056（HTTP CONNECT），流量经 tailscaled 转发进 tailnet。 - 完整 TUN 模式.设备层接管路由，但目前只有部分 Kindle 型号能跑，不是全系支持。
受益最直接的是已经在用 KOReader、又想连自建服务的人：Calibre/OPDS 书库、Wallabag 稍后读、Audiobookshelf 有声书、自建 RSS 源，甚至用 Readest 同步阅读进度。还没越狱、只是想买台电子书阅读器的人，这波更新不构成新增理由。
代理和 TUN，分别补哪一层
老版本的用户态模式，本质是让 Kindle 在 tailnet 里“被看见”。外部设备能主动连进来，但 Kindle 自己发起的连接够不到 100.x.y.z，系统压根不知道这个地址该怎么走。
代理模式解决的是“出”的问题。它不改设备路由表，只让 KOReader 把请求先丢给本机的 SOCKS5/HTTP CONNECT 端口，剩下的路由交给 tailscaled。这是应用层补丁，只有配置了代理的那个 App 能享受，浏览器和其他插件该不通还是不通。
完整 TUN 模式才是设备级方案：整机路由都走 tailnet，理论上不用逐个 App 配代理。但这只在部分 Kindle 上能跑，不能当成全机型能力。
| 模式 | 解决什么 | 局限 |
|---|---|---|
| 用户态（旧） | 设备可被外部看见、连入 | App 无法主动连出 |
| 代理模式 | 单个 App（如 KOReader）可连出 | 只对配置过代理的 App 生效 |
| 完整 TUN | 设备级路由，全局生效 | 仅部分 Kindle 型号支持 |
如果不确定自己的机型是否支持 TUN，代理模式是更稳的起点——配置成本低，只改一个 App 的设置，出问题也容易回退。TUN 更彻底,但目前更像“能跑就是运气好”，不是可以放心依赖的路径。
风险也要说清楚：这整套建立在越狱、旧固件窗口和手动填 authkey 的基础上。设备本身不受官方支持，authkey 泄露、固件更新覆盖越狱状态，这些维护成本都得自己认。
另外有一个独立的 KOReader 插件方案，思路更轻——不靠 KUAL，直接在 KOReader 里装插件、填 key、开代理。它标注测试过 Kindle PW5/PW6、部分 Kobo 和 PocketBook，覆盖面比之前只认 Kindle 宽一些。但它不等于 KUAL 那套完整方案，也不会让设备本身在 tailnet 外部可被访问。原作者自己那台 11 代标准版 Kindle，目前就跟这个插件合不来——兼容性坑是真实存在的,不是个例。
锐评
代理模式解决的是 KOReader 出得去这一件事,对已经把 Kindle 当自托管阅读终端在用的人是刚需级修复。折腾出一个 tailnet，结果核心用例连不上，这个补丁本该更早出现。
也别把这次更新想得太美。TUN 只在部分机型上生效，KOReader 插件在不同硬件上表现参差,连开发者自己的设备都踩了坑。Amazon 不会给这套东西背书，Tailscale 官方博客只是记录社区的进展。越狱、旧固件窗口、手动认证密钥，每一步都要自己扛风险。
这依然是极客玩具,不是大众产品。真正值得盯的变量,是 KOReader 插件往 Kobo、PocketBook 扩散的速度——如果它能在更多电子墨水设备上稳定跑起来,才算真的从“给 Kindle 顺手加个功能”变成一整类阅读设备的自托管入口。现在,还只是前者。