我写了个 CLI 工具，把云服务器流量转回本地代理：LocalTUN

fishwww_ww
0 阅读6分钟

写在前面

笔者是在搓完这个项目之后, 才发现有更好的方式来实现服务器代理, 所以本文并不是一个常规的代理方案, 只是作为笔者在学习计算机网络中的思考和探索

正文

平时用云服务器开发、拉依赖、跑脚本、测试海外接口时，很多人都会遇到一个很烦的问题：

本地网络环境已经配置好了代理，比如 Clash、Mihomo、Surge、V2Ray 这些都在本机稳定运行；但到了远程服务器上，又得重新折腾一套代理环境。

这件事的问题不只是“麻烦”，而是它很容易变成重复劳动：

  • 本地已经有一套可用代理
  • 服务器上还要再装一套
  • 换机器、换端口、换配置时又得重新改
  • 有时候服务器环境简陋，装代理本身都不方便
  • 代理挂了以后，排查到底是服务端问题还是本地问题也很费劲

所以我做了一个小工具：LocalTUN。

github仓库: fishwww-ww/LocalTUN

它的核心思路很简单：

通过 SSH 反向隧道，把远程服务器上的代理流量转发回你本地已经跑着的代理端口。

也就是说，服务器不用自己维护一套代理栈，而是直接“借用”你本机的代理能力。

它解决了什么问题？

举个最实际的场景。

我的本地机器上已经跑着 Mihomo，HTTP 或 mixed 代理端口是 7897。
我有一台云服务器，需要临时：

  • 拉一些外部依赖
  • 访问某些海外接口
  • 用 curl 做接口联调
  • 跑一些依赖外网的脚本

传统做法通常是：

  • 在服务器上安装代理程序
  • 配置订阅、规则或节点
  • 处理守护进程、端口监听、防火墙、环境变量
  • 出问题了还要逐层排查

而 LocalTUN 做的事情是：

  • 本地运行一个命令
  • 它通过 SSH 建立反向隧道
  • 在远程服务器暴露一个端口，默认是 1080
  • 这个端口收到的流量，会被转发到你本地代理端口，默认 7897
  • 然后由你本地的代理客户端负责最终出网

整个路径大概是这样：

远程服务器 (:1080) -> SSH 反向隧道 -> 本地机器 (:7897) -> 本地代理客户端 -> Internet

所以它很适合下面这些场景：

  • 云服务器想复用本地 Clash / Mihomo 代理
  • 临时机器不想装完整代理环境
  • 想让远程脚本、curl、包管理器快速获得代理能力
  • 希望代理配置尽量集中在本地维护，而不是每台服务器都重复配置

为什么不直接手写 SSH 命令？

当然，你完全可以自己手敲 SSH 反向隧道，比如类似这种思路：

ssh -R 1080:127.0.0.1:7897 user@server

但真正落地时，问题很快就会变多：

  • 远程 sshd 是否允许端口转发
  • 是否打开了 GatewayPorts
  • 断连后怎么自动重连
  • 后台进程怎么托管
  • PID、日志怎么管理
  • 远程环境变量怎么统一配置
  • 如何快速验证链路真的可用

这些零碎事情单个看都不难，但组合起来就很容易变成一堆临时脚本和手工操作。

LocalTUN 的意义，其实就是把这些重复动作产品化、命令化。

3 分钟上手

0. 安装

homebrew 安装

brew tap fishwww-ww/tap
brew install fishwww-ww/tap/localtun

npm 安装

npm i @fishwww-ww/localtun

更多安装方式详见仓库

1. 初始化配置

先执行：

localtun init

它会引导你输入这些信息：

  • 服务器 IP 或域名
  • SSH 用户名
  • SSH 端口
  • SSH 私钥路径
  • 远程代理端口
  • 本地代理端口

默认配置文件路径是：

~/.localtun/config.yaml

配置大概长这样：

server:

host: 1.2.3.4

port: 22

user: root

key_path: ~/.ssh/id_rsa

tunnel:

remote_port: 1080

local_port: 7897

keepalive:

interval: 30

max_count: 3

2. 初始化远程服务器

第一次在目标服务器上使用时，执行：

localtun setup

这个命令会连接到服务器，并在确认后帮你做几件事：

  • 备份并修改 /etc/ssh/sshd_config
  • 开启 AllowTcpForwarding yes
  • 开启 GatewayPorts yes
  • 开启 PermitTunnel yes
  • 视情况重启 SSH 服务
  • 备份并更新远程 ~/.bashrc
  • 注入代理环境变量和辅助函数

这一步的价值很大，因为很多 SSH 反向隧道“命令没错但就是不通”的根因，往往就在服务端 SSH 配置上。

3. 启动隧道

前台运行：

localtun start

后台运行：

localtun start -d

后台模式下会生成：

  • ~/.localtun/localtun.pid
  • ~/.localtun/localtun.log

这意味着你可以把它当成一个稳定的常驻通道来用，而不是每次开一个终端窗口盯着。

4. 查看状态

localtun status

它会告诉你：

  • 当前是否在运行
  • 进程 PID
  • 服务器地址和用户
  • 远程端口到本地端口的映射
  • Keepalive 配置
  • 日志文件路径

对于排障来说，这一步很实用，因为你不用自己再去翻进程列表或者猜日志位置。

5. 验证代理链路

localtun test

这个命令会从远程服务器侧去验证整条代理链路是否通畅，比如测试访问：

  • https://www.baidu.com
  • https://www.google.com

它能帮你快速确认几件事：

  • 隧道有没有建立成功
  • 本地代理端口是否可达
  • 远程代理环境是否正确生效

6. 停止隧道

localtun stop

后台模式下停止也比较干净，不需要你手动找 PID 再 kill。

这个项目比较看重的几点

1. 它尽量贴近真实使用习惯

很多人实际已经有本地代理了，问题不在“怎么代理”，而在“怎么把远程机器接进来”。

LocalTUN 不是重新发明代理工具，而是补上这层连接能力。

2. 它把远程侧配置也收拢了

远程服务器最容易出问题的地方之一，就是 SSH 服务配置和 shell 环境变量。

如果每次都手动改 /etc/ssh/sshd_config、改 ~/.bashrc、再自己测连通性，重复劳动真的很多。

把这些能力放到一个 CLI 里，整体体验会顺很多。

当前限制和注意点

项目目前也有一些边界：

  • 当前主要基于 SSH 私钥认证，不支持交互式密码登录
  • 远程环境主要依赖 HTTP 代理环境变量，所以更推荐本地提供 HTTP 或 mixed 代理端口
  • SSH host key 校验目前偏宽松，敏感环境里需要自己额外评估安全风险
  • setup 会修改远程系统文件，生产环境建议先确认备份和回滚方式

我个人更倾向于把它定位成：

一个个人开发者、自用服务器场景的效率工具。

avatar
文章
阅读
粉丝