前言
你可能在使用一个没有可用的翻墙客户端的平台.
你可能觉得目前能找到的翻墙客户端太大, 太笨重了, 你用不到那么多功能, 用不到那么多协议.
你可能看到了某个翻墙内核新出了一个协议, 而你手里的翻墙客户端还没有支持.
你可能就是手痒, 想自己搓轮子.
那么你可以做一个你自己的 翻墙客户端
思路
考虑到翻墙内核都是用go语言, 那么我们的翻墙客户端也用go. 这样, 内核能跑的平台, 客户端也能跑.
客户端的GUI界面部分, 考虑到覆盖尽量广的平台, 以及方便用户自己修改调整界面元素, 用HTML.
探索
以 xray 翻墙内核 + reality协议 为例
启动一个hermes, 对接 mimo-v2.5.
设计工作从这样的对话开启
我们来分析一个翻墙客户端(壳)的设计方案.
基于xray内核
考虑到覆盖尽可能广的平台, 翻墙客户端的后端基于 go 语言
考虑到方便用户自定义界面, 翻墙客户端的界面基于 HTML
你觉得如何?
很多细节和反复拉扯的部分在此省略. 只记录一些最终保留的重要设计思路
前后端功能设计
后端只负责替换配置文件 和 启/停翻墙内核
前端将配置文件的全量文本发给后端
前后端API设计
配置文件操作 — /api/files
GET /api/files
GET /api/files/{filename}
PUT /api/files/{filename}
DELETE /api/files/{filename}
进程操作 — /api/core
GET /api/core/status
POST /api/core/start
POST /api/core/stop
POST /api/core/test
设计前端时, 为了简化, 预设以下一些约束条件
后端的配置文件只会有这一些, 只会少, 不会多.
01-log.json # log
02-dns.json # dns 配置
03-router.json # routing rules
04-inbounds.json # 入站监听
05-outbounds.json # 出站代理
06-api.json # commander API
只实现最基本的核心功能作为演示,
只需要使用这些API
GET /api/files/{filename} → { content }
PUT /api/files/{filename} ← { content } (创建或替换)
POST /api/xray/start
POST /api/xray/stop
前端HTML的使用方式
后端不提供HTTP文件路由
前端HTML文件可以由单独的HTTP服务来支撑, 如 python -m http.server
前端HTML文件也可以直接用浏览器打开
前端HTML页面思路
前端为每个配置文件生成一个HTML页面文件
01-log.json
02-dns.json
03-router.json
04-inbounds.json
05-outbounds.json
06-api.json
前端的页面设计
对于不是 outbound 的页面, 只有直接编辑JSON 的功能, 没有表单
所以它们应该是几乎一样, 只有文件名不一样.
前端outbound页面的设计
转JSON
• 行为: 表单 → 生成 JSON → 填入下方 JSON 编辑器（不保存）直接保存
• 行为: 表单 → 生成 JSON → 填入下方 JSON 编辑器 → 发送给后端保存
• 行为: JSON 编辑器的内容 → 发送给后端
后端设计1个yaml格式的配置文件
listen: 127.0.0.1
port: 18080
files-dir: ./bin/xray/
core-start: “./bin/xray/xray run -confdir ./bin/xray/”
core-test: “./bin/xray/xray run -confdir ./bin/xray/ -test”
log: “”
上传 Github
G站/crazypeace/my-dream-proxy-client
- 对, 我取了一个特别的名字 my-dream-proxy-client 但其实功能特别简陋, 只是演示了最基本的工作原理. 哈哈!
使用方法
见 Github 项目 README.md
G站/crazypeace/my-dream-proxy-client/blob/main/README.md#my-dream-proxy-client-使用手册-配合xray内核
具体开发过程
hermes 对接 mimo-v2.5 开发翻墙客户端(壳) 基于 xray 内核 reality 协议
1 个帖子 - 1 位参与者