它不是想取代某个成熟工具，也不打算做成什么都管的“大杂烩”。OmniPilot 只收纳那些确实贴合我自己日常习惯的功能。目前，它主要做两件事：管理 SSH 隧道，以及保存文本剪贴板历史。

从 SSH 隧道开始

我在 ~/.ssh/config 里已经配置好了服务器和端口转发，但每次开机、待机或网络切换之后，都需要手动启动隧道，还得留意连接有没有断。

OmniPilot 直接读取 SSH 配置，找出声明了 LocalForward 或 RemoteForward 或 DynamicForward 的 Host，并为每个 Host 启动一个 ssh -N <alias> 进程。隧道意外退出时，应用会按 1、2、5、10、30 秒的间隔自动重连；连续失败则通过系统通知提醒我。整个过程不修改 SSH 配置，也不接管密钥或认证，仍然使用系统已有的 ssh-agent。

这种设计的好处是，连接信息仍由 OpenSSH 管理，OmniPilot 只负责“启动、监督和展示状态”。菜单栏里可以查看每条隧道及其转发信息，也可以单独或批量启停。

再加一个常见的小功能

剪贴板历史是我后来加入的第二个功能。它每 0.8 秒检查一次系统剪贴板的变化，只有内容变化时才读取，并且当前只保存文本。

菜单栏面板里可以查看历史、删除单条记录，或清空全部内容。历史条数可以选择 10、20、30、50 或 100 条，默认 30 条。点击一条历史记录会把文本写回系统剪贴板，之后我可以在目标应用里按 ⌘V 粘贴；它不会替我模拟键盘输入。

剪贴板内容保存在 ~/Library/Application Support/OmniPilot/clipboard-history.json，条数设置则通过 UserDefaults 保存。历史文件是普通 JSON，没有加密，所以它可能包含敏感文本；应用会过滤常见的隐藏、临时和密码管理器标记，并提供单条删除和清空操作，但这不等于安全存储。

菜单栏之外的代码结构

这个项目是我学习 Xcode 和 Swift 开发时逐步搭起来的。代码按“应用外壳”和“可测试的核心逻辑”分成两层：

• Sources/OmniPilot 是 macOS App 本身，放菜单栏界面、剪贴板监控、通知和登录项等系统集成。
• Packages/OmniPilotKit 是本地 Swift Package，放 SSH 配置解析、隧道进程管理，以及剪贴板历史模型和持久化逻辑。
• project.yml 描述 Xcode 工程，由 XcodeGen 生成 OmniPilot.xcodeproj。

把逻辑放进 Swift Package 的一个直接收益是可以独立测试。例如剪贴板历史的去重、条数限制、持久化和清空行为，都可以通过 swift test 验证，不需要启动菜单栏界面。

构建和试用

项目面向 Apple Silicon，最低支持 macOS 13。安装 Xcode 和 XcodeGen 后，可以这样构建：

brew install xcodegen
Scripts/build-app.sh
open build/OmniPilot.app

运行核心逻辑测试：

cd Packages/OmniPilotKit
swift test

应用日志写入 ~/Library/Logs/OmniPilot/omnipilot.log。打包脚本支持生成 zip 或 dmg；更完整的签名、公证和 Gatekeeper 说明可以查看 Docs/distribution.md。

一个只为自己服务的小工具

OmniPilot 的方向不是“菜单栏里还能塞什么”，而是“我自己的工作流里，有什么值得放到这里”。它不试图替代其他成熟，常见的菜单栏应用，也不追求功能数量；它只把 SSH 隧道和剪贴板历史这类我确实需要的东西，放到一个随手可用的位置。

后续要不要增加新功能，我也会沿用同一个标准：只有它能解决我自己的真实麻烦，且具备个性化的需求，才值得进入 OmniPilot。

项目地址

• GitHub：https://github.com/drofyn/omnipilot

大陆机房服务器的日常痛点,每个运维都懂:

• git clone GitHub 仓库,克隆到一半断连、超时
• docker pull 官方镜像仓库,进度条卡死
• pip install / npm install 海外源,慢如蜗牛
• 想连 Google 系 API,直接不可达
• 更隐蔽的:DNS 污染/劫持,域名解析到错误 IP,业务流量被"换包"

常规方案为什么不彻底

最常见的做法是 http_proxy / socks5 环境变量:

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

它有几个硬伤:

• 只对显式支持代理协议的程序生效。docker daemon 要单独配 proxy 配置、git 要单独配、很多 CLI 工具根本不认环境变量,漏一个程序就裸连被墙
• 环境变量是全局侵入。curl 一个内网地址也会先走代理,日志里到处都是代理 IP,还可能误伤内网流量
• DNS 不处理。环境变量代理只代理 TCP 数据,域名解析还是本地 DNS 做——污染/劫持问题依旧存在
• 按进程粒度配置。服务器上跑着几十个进程,不可能每个都去配

sing-box:TUN 透明分流

sing-box 的思路完全不同:它创建一张虚拟网卡(TUN),在内核层面接管整个系统的流量。所有应用的流量先进这张虚拟网卡,进入用户态后由 sing-box 按规则路由,应用完全无感知——不配任何环境变量,所有程序(包括 docker daemon、包管理器、任意 CLI)自动被分流。

配合DNS 分流和规则集,可以做到:

• 国内域名(geosite-cn)→ 大陆 DNS(如 223.5.5.5)解析,大陆出口直连
• 海外域名 → 海外 DNS(如 8.8.8.8,通过代理链路转发)解析,从源头杜绝污染
• 流量按 geosite/geoip 规则自动分流,无需逐进程配置

单机双 IP + 远端代理的典型架构

很多大陆服务器有双出口(一条大陆线路、一条香港/海外线路),或者有一台海外 VPS 做代理。sing-box 可以把这两者组合成一套完整的分流体系:

"outbounds": [
  { "type": "direct", "tag": "direct-mainland", "bind_interface": "eth2" },
  { "type": "direct", "tag": "direct-hongkong", "bind_interface": "eth1" },
  {
    "type": "vless",
    "tag": "proxy-hk",
    "server": "你的香港VPS地址",
    "server_port": 443,
    "uuid": "...",
    "tls": { "enabled": true }
  }
],
"route": {
  "rules": [
    { "rule_set": ["geoip-cn", "geosite-cn"], "action": "route", "outbound": "direct-mainland" }
  ],
  "final": "proxy-hk"
}

要点:

• 国内流量:geoip-cn / geosite-cn 命中 → direct-mainland 直连,延迟最低,不浪费代理带宽
• 海外流量:未命中规则 → final: proxy-hk,走香港 VPS 的 vless/trojan 隧道,彻底翻墙
• DNS:国内域名走大陆 DNS,海外域名走香港 DNS(detour 到代理链路),双保险防污染
• 单机只有一根出口线的场景也一样:把 direct-mainland 换成默认直连,海外流量全部走代理即可

为什么比 tproxy 更现代

Linux 上做透明代理,老派方案是 tproxy + iptables/nftables。tproxy 本身没错,但用它搭一套完整分流要面对:

• iptables/nftables 规则繁琐,REDIRECT vs TPROXY 的区别、IPv4/IPv6 双栈规则、UDP 处理,边界情况极多
• DNS 劫持要自己用 dnsmasq/iptables 拼装
• 规则更新(geoip 数据库)要自己下载、转换、重载 iptables
• 换一台机器就要重新调一遍,可迁移性差

sing-box 把这些全部收敛进一个配置文件:路由规则、DNS 分流、出站选择都是声明式配置,规则集(geosite/geoip)自动从远端更新,配置即代码,迁移成本几乎为零。它还自带 sniff(流量探测)、直连/代理健康检查、负载均衡等能力,生态比 tproxy 时代完整得多。

小结

在无法直接访问 GitHub、Docker Registry、Google 的大陆服务器上,sing-box 用一张虚拟网卡 + 声明式规则,把"国内直连、海外代理"的分流做到了系统级透明:不需要为每个程序配代理,不污染环境变量,不依赖脆弱的 DNS,配置可版本化、可迁移。相比 http_proxy/socks5 的"半吊子代理"和 tproxy 的"手工拼装",它是更彻底、更现代、更好维护的答案。

一个跑在 OpenWrt 路由器上的零依赖局域网协作服务——共享剪贴板、文件公告板、WebRTC 点对点传文件,以及配套的 LuCI 管理界面。

为什么做这个

跨设备传文件、同步一段文字或链接,是家庭、办公室、宿舍里最高频也最碎片化的需求。但现有的方案总有让人不舒服的地方:

• 要登录第三方账号,隐私和依赖都交出去了;
• 大文件走公网云中转,速度受限、流量有成本,还可能在途中被看;
• 没公网或弱公网环境直接不可用;
• 每台设备都得装客户端,手机、电脑、平板、同事的机器……装一遍就劝退一半人。

而每个家庭/办公室几乎都有一台 7×24 小时开机的东西——路由器。它天然就在局域网的中心,天然常驻,天然被所有设备信任。那为什么不能把路由器本身变成一个"随时可用的本地共享空间"?

这就是 Nook 的出发点:

• 零客户端——浏览器打开即用,不用装任何 App;
• 零公网依赖——不需要外部服务器、云账号、公网链路,断网也能用;
• 本地优先——文件内容不落路由器磁盘,尽量在设备之间点对点直传;
• 路由器即入口——开机常驻,永远在同一个地址等你。

项目形态

Nook 包含两个仓库:

1. nook——Go 编写的核心服务,跑在 OpenWrt/ImmortalWrt 上,提供 Web 页面 + WebSocket 信令 + 内存态协调(Hub)。
2. luci-app-nook——配套的 LuCI 应用,在 OpenWrt 管理界面 Services → Nook 里查看服务状态、启停服务、配置监听地址。

两个包都是标准 OpenWrt 打包(nFPM 生成 ipk / apk),覆盖 aarch64_cortex-a53 和 x86_64 两种架构,CI 在打 v 开头 tag 时自动构建发布。

能做什么

打开 http://路由器地址:8088 之后:

• 局域网设备自动发现——所有打开页面的设备实时出现在在线列表里,离线自动移除;
• 共享剪贴板——发布一段文本/链接,局域网内所有设备实时同步;自动识别 URL 可点击;每条支持复制,还带系统剪贴板 Paste;
• 文件公告板——把文件"发布"到公告板,其他设备点一下就能领取;支持多文件、单条撤回、一键清空自己的公告;
• 直接发送——在设备列表里点某个设备,直接给它发文本或文件,对方弹窗接受/拒绝;
• 设备命名——自定义设备名,可记忆(刷新后保留),可一键重置回自动生成的默认名(按 UA 生成 + 随机后缀)。

关键设计:文件内容不经过路由器

这是 Nook 最核心的设计决策:默认不把文件存到路由器上。

文件公告板只在路由器内存里保存文件的元信息(文件名、大小、MIME、发布者、发布时间)。真正的文件内容始终留在发布者的浏览器里;其他设备点击领取时,通过 WebRTC DataChannel 在设备之间点对点传输,路由器只做信令中转。

对应的取舍:

• 发布者的页面需要保持打开、设备保持在线;
• 发布者刷新页面或关浏览器,相关公告自动失效;
• 路由器不持久保存文件内容——低端路由器的存储和 CPU 都不会被大文件拖垮。

架构

路由器 (OpenWrt)
┌──────────────────────────────────────┐
│  /usr/bin/nook  (单二进制, 前端已嵌入)  │
│   - HTTP: /  /ws  /config             │
│   - Hub: 内存态 (peers/clipboard/offers)│
└──────────┬───────────────┬────────────┘
   WebSocket (信令/元信息)    HTTP (页面)
           │                │
     ┌─────▼─────┐    ┌─────▼─────┐
     │ 设备 A     │    │ 设备 B     │
     │ 浏览器     │◄──►│ 浏览器     │
     └───────────┘WebRTC└───────────┘
        文件内容 P2P 直传, 不经过路由器

技术栈刻意保持极简:

• 后端:Go 标准库 + gorilla/websocket + google/uuid,全部代码约 600 行(不含前端);
• 前端:纯 HTML/CSS/JS,零第三方依赖,通过 embed.FS 打进单二进制——部署就是一个文件 + init.d 脚本 + UCI 配置;
• 宿主集成:procd 管理、respawn 自动重启、/etc/config/nook 标准 UCI 配置。

WebSocket 协议

设备通过 /ws 注册,消息是 JSON,核心类型:

• hello / welcome——注册与全量状态下发(自身 ID、在线设备、剪贴板、文件公告);
• peer-joined / peer-left——上下线广播;
• clipboard-add / clipboard-added——剪贴板发布与广播;
• file-board-add / file-board-added / file-board-remove / file-board-removed——公告板增删;
• file-board-request / file-board-unavailable——领取请求与失败;
• signal——WebRTC offer/answer/ICE candidate 的定向转发。

文件传输协议(DataChannel 内)

发送方先发 file-offer(文件名/大小/MIME),接收方回 file-accept 或 file-reject,然后按 64 KB 分块流式发送二进制,最后 file-done 收尾。状态机:waiting → accepted → sending → done,或 rejected / error。公告板领取和直接发送共用这套机制。

一些工程细节

• WebSocket 升级时做 Origin 校验,防跨站 WebSocket 劫持;
• 心跳 Ping 30 秒,读超时 60 秒,写超时 10 秒,空闲连接不被误杀;
• 单条消息上限 64 KB;剪贴板最多 50 条、单条 64 KB;公告板最多 100 条;
• 优雅关闭:收到 SIGINT/SIGTERM 后 5 秒内收尾;
• 设备 ID 用 UUID 前 8 位,不可预测;
• 前端断线 3 秒自动重连,重连后重新注册拉全量状态。

配套的 LuCI 界面

luci-app-nook 让 Nook 融入 OpenWrt 原生管理体验:

• 后端是 ucode 写的 rpcd 插件(luci.nook),暴露 get_status 和 service_action 两个方法;
• 状态页显示 running(运行中)和 enabled(开机自启)两个状态,一键 start/stop/restart/enable/disable;
• 配置页读写 /etc/config/nook 的启用开关和监听地址,改配置自动触发服务重载;
• 同时兼容 LuCI 23.05 和 24.10(通知 API 做了降级);
• 权限走标准 ACL,最小授权:读状态 + 写 nook 配置 + 执行 init.d 脚本。

安装与使用

# aarch64 / x86_64 按架构选包
opkg install ./nook_0.1.6-1_aarch64_cortex-a53.ipk
# 或 apk 包管理器(未签名本地包)
apk add --allow-untrusted ./nook_0.1.6-r1_aarch64_cortex-a53.apk

/etc/init.d/nook enable
/etc/init.d/nook start

然后同一局域网内访问 http://192.168.1.1:8088 即可。升级行为也考虑过:首次安装不自动启动;升级时若服务正在运行则自动重启,未运行则不打扰。

设计取舍与边界

Nook 明确不做的事,和做了一样重要:

• 不做公网/跨网传输——只面向同一局域网;
• 不做账号体系——没有登录、没有云同步;
• 不做持久化——剪贴板、在线设备、公告都是内存态,服务重启即清空(已接受的取舍);
• 不做认证加密——当前版本基于"可信局域网"假设;没有端到端加密,局域网内流量可被嗅探。这一点在文档里写得很清楚,后续版本会评估设备配对与传输加密。

小结

Nook 解决的是一个小而真实的问题:在局域网里,设备之间应该能像在同一个房间一样自然地交换东西。它把"路由器"这个每家都有的基础设施变成了协作入口,用浏览器消灭客户端,用 WebRTC 让文件内容绕开路由器,用最克制的技术栈(Go + 原生前端 + 标准 OpenWrt 打包)换来低端路由器上也能跑的轻量体验。

代码在 GitHub,欢迎围观和提 issue:

• drofyn/nook
• drofyn/luci-app-nook