ICDYCT / 我能, 你也行 / I Can Do, You Can Too

前言 前面我们 基于MDPC-my-dream-proxy-client 很容易实现了一个 hy2 翻墙客户端(壳) 再来试试 sing-box 和 anytls 协议 面向GPT开发 开发人员: Hermes 对接 mimo-v2.5 学习知识 把 https://github.com/SagerNet/sing-box 按最新的 release tag clone一份本地代码. 不要放tmp, 未来要进一步分析. 是长期任务. 分析 sing-box 的使用方法, 配置文件用什么格式 用怎样的命令形式启动 sing-box 内核 有没有测试 配置文件 是否合法的 sing-box 命令? 这是 sing-box 的文档 https://sing-box.sagernet.org/  对照 你的分析, 进行对比验证 把你的分析结论保存为 .md 文件 我要使用 sing-box 的 anytls 协议 你分析源码找到应该如何使用, 包括服务端 和 客户端 另存为一份 .md 文件 开发 - 基本功能 基于 /home/ubuntu/my-dream-proxy-client/ 这个项目进行开发 你先学习一下这个项目 现在要继续 开发支持 sing-box 内核 支持 anytls 协议  参考以下分析报告 - ~/repos/sing-box/ANALYSIS.md — 项目分析（配置格式、启动命令等） - ~/repos/sing-box/ANYTLS.md — AnyTLS 使用指南 先不要实施编码, 先和我讨论设计思路 sing-box 也是独立实例 API 端口 18280 sing-box 配置文件 多文件同目录 启动命令 sing-box run -C confdir/ 确定每个配置文件中只有一个json块,  比如, inbound.json 里面只有 inbound ,  outbound.json 里面只有 outbound 类似 xray 的处理方式, 对每个 json 配置文件, 都有一个HTML页面. 先只实现JSON文本编辑框, 表单以后再设计. 测试和调试 略 功能类的测试, 先让Agent自己搭环境测试, 遍历各种组合环境. 最后再由人上手. UI设计, 操作逻辑, 这些由人设计, 由人测试, ...

前言 前面我们实现了一个 配合xray内核 reality协议 的 极简翻墙客户端(壳) MDPC-my-dream-proxy-client   如果我们想 配合 Hysteria 内核呢?  (只为了简单演示, 所以只处理自签证书的情况) 分析 根据 my-dream-proxy-client项目 (下称MDPC)的设计, MDPC的配置文件参数为: listen:  port:  files-dir:  core-start:  core-test:  log:  我们可以填上 hy2 对应的信息, 如: listen: "127.0.0.1" port: "18180" files-dir: "./bin/hy2/" core-start: "bin/hy2/hysteria client -c bin/hy2/config.yaml" core-test: "" log: "" 这样后端就好了. * 是不是很简单! 接下来就是创造前端的HTML, 用来生成hy2客户端配置文件的yaml文本 可以先从简单的YAML文本编辑框作为基础功能. 然后再加表单. 开发过程 Github https://github.com/crazypeace/my-dream-proxy-client 使用方法 见 Github 项目 README.md https://github.com/crazypeace/my-dream-proxy-client/blob/main/README.md#my-dream-proxy-client-使用手册-配合hysteria内核 ======== 后记 本次开发由 hermes 对接 mimo-v2.5-pro

前言 你可能在使用一个没有可用的翻墙客户端的平台. 你可能觉得目前能找到的翻墙客户端太大, 太笨重了, 你用不到那么多功能, 用不到那么多协议. 你可能看到了某个翻墙内核新出了一个协议, 而你手里的翻墙客户端还没有支持. 你可能就是手痒, 想自己搓轮子. 那么你可以做一个你自己的 翻墙客户端 思路 考虑到翻墙内核都是用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...