鸿蒙原生的极简隧道:Hey 与 ArkTS 原生网络协议调试工具
基于华为鸿蒙 ArkTS 纯自研语言体系,打造简洁清爽、高安全性的移动端网络隧道工具
时代与新系统平台网络协议栈调试匮乏的困境
在全自研操作系统早期,生态内普遍缺少轻量、专注于网络隧道与协议排错的自研工具。许多开发者在排查网络连通性或进行移动端网络抓包与路由测试时,苦于没有趁手、原生适配 HarmonyOS NEXT 的轻量级助手。[1]
基于华为鸿蒙 ArkTS 纯自研语言体系,打造简洁清爽、高安全性的移动端网络隧道工具
在全自研操作系统早期,生态内普遍缺少轻量、专注于网络隧道与协议排错的自研工具。许多开发者在排查网络连通性或进行移动端网络抓包与路由测试时,苦于没有趁手、原生适配 HarmonyOS NEXT 的轻量级助手。[1]
基于 ArkTS 开发的 HarmonyOS NEXT 开源网络隧道与协议调试工具,支持 Xray 与 sing-box 核心。
基于 HarmonyOS NEXT 开发的原生网络隧道与协议调试客户端
代码或许归档,但火种永不熄灭。为推动网络对抗演进与底层工程突破的开拓者献上一份敬意。
在支持 libXray v26.7.28 的问题讨论中,作者更新:v1.3.5 已升级到 libXray v26.7.28(工具链换成 star4277/ohos-go v1.26.5)。此前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV(日志停在 VPN created,没有 Xray started);根因是自身桥接代码:新版 libXray 加载后又调用 setenv 设置资源目录,而 Go 的 c-shared 库在 dlopen 返回后会另…(节选)
感谢反馈,信息很有用 🙏 已核实:`star4277/ohos-go` v1.26.5-beta1 确实带 OpenHarmony 端口(`GOOS=openharmony` + `rt0_openharmony_arm64.s`,还修了 go1.26 的 OHOS musl 早期初始化问题),正好解开当前的死结——现役工具链封顶 go1.24.5,而 libXray v26.7.28 需 go1.26.3、新版 xray-core 需 go≥1.25。 计划分阶段推进: 1…(节选)
感谢反馈,两点都已处理: 1. **Hy2 测延迟失败**:Hysteria2 走 QUIC/UDP,而测延迟是对服务器端口做 TCP 握手,该端口通常只监听 UDP,故必然失败(节点本身可正常使用)。已改为不再误报为"失败"、显示中性状态;要测出真实延迟数字需后续为 sing-box 增加原生测速,会继续跟进。 2. **测速偏低**:已在 tun2socks 数据面开启接收窗口自动调优,缓解高带宽/高延迟链路上单流被固定窗口卡住的问题,整体吞吐会有提升。下个版本(经真机验…(节选)
小传正文中的关键事实与时间点均基于以下公开一手记录或权威报道:
基于 popsiclelmlm 官方公开代码仓库、设计文档与 Git 提交记录整理,严格遵循公共文献边界。
写明需要纠正的内容,可附相关链接。资料会在人工核验后更新。