hxmy proxy —— 你的pixel 手机也可以是超级代理服务器（2026.8.15)）

谷歌商店的链接https://play.google.com/store/apps/details?id=com.mzstd.hxmyproxy ，

经过过去一个月的测试，现在这个app已经趋于完善了，稳定性大大增强，UI也进一步优化了，另外增加了无缝流转功能，
目前mac os我开发了一个脚本（要的话我可以再发一下），自动切换ip，只要这个手机开启这个应用，电脑和手机连接同一个网络，
就可以做到随时随地的上网，无需进行再次配置ip等等操作，目前可用性是非常不错的 ，
果然只有自己在用的app才会越来越好，之前一腔热血开发的app连自己都不用，都是雨声大雷点小，一会就不更新了，
稍后还有hxmy asset（代替fortune city，台湾开发的一个记账应用）（全球资产集于一个app），
hxmy task（代替Google task）， hxmy note（代替印象笔记）即将上线，围绕隐私交互设计的app，
这些都是我日常使用频率非常高的应用，大概至少使用有超过3年，所有这次会全部进行一些替换解决app的很多痛点，
大伙也可以提提意见

先说这个app的起因。
Android 17 推送那天，我手机升完，Every Proxy 就不能共享了。别的设备连不上，
不报错，就是连不通。查了一圈才知道是系统新加了一个本地网络权限
ACCESS_LOCAL_NETWORK，targetSdk 到 37 的应用，做任何局域网通信之前都得先申请它。
没申请的话，LAN 流量直接失败，而且不崩溃、不报错，就是静悄悄地不通。
    https://developer.android.com/pr ... -network-permission

代理这类软件整个业务就在局域网上，这一刀正好砍在命门。Every Proxy 当时没跟上，
我就那么被卡住了。

其实在那之前我就攒了一肚子火。用它的过程中碰到过好几个问题，
换网之后要重启才恢复、某些域名偶尔连不上之类的，但代码不是我的，
我除了等更新什么也做不了。

那天干脆自己动手写了一个。


────────────────────────────────

这东西到底解决什么问题

Pixel 7 以后的机器自带一项 Google 魔法服务，官方说明在这：
    https://support.google.com/pixelphone/answer/2819573

好用是好用，但它只保护手机自己。你家电视、Switch、iPad、笔记本，一个都沾不上。
这些设备要么没地方配，要么配了也没用。

想让它们也走上那条线路，流量就必须先进到手机里，再由手机发出去。
而且必须经过一个 App，直接开热点是不行的，热点那条路是内核转发的，
数据包压根不经过任何应用，也就跟你手机上装了什么服务没关系。

所以这个 App 干的事很简单：在手机上监听一个端口，别的设备把它当代理，
流量进来之后由这个 App 转出去，走的就是手机上选定的那条线路。
其他设备什么都不用装，填个地址就完事。


那你会问了，路由器不能干这事吗？答案是不能

规则、广告拦截、流量统计，这些路由器全都能干，而且 pi-hole、AdGuard Home
这些方案比我成熟得多，我一点不否认。

但路由器拿不到 Google 魔法服务。那东西绑在 Pixel 上，只有手机自己能用。
你在路由器上写再多规则，电视的流量也走不上那条线。

这就是这个 App 唯一不可替代的地方。没有这层共享，我这东西确实没什么存在的必要。
所以受众也很明确：手上得是 Pixel 7 或更新的机器。不是这个机型，
最大的那个用处就没了，剩下的功能路由器都能替你干。


────────────────────────────────

既然流量都从这过了，顺手做的几件事

流量已经经过这一跳了，不做点什么也是浪费。

一是广告和追踪拦截，内置 61063 条。这块有个细节挺多人不知道：
我是在拿到目标域名之后、去查地址之前做的判断。HTTPS 的 CONNECT 请求
按协议必须明文带上目标域名，所以客户端拿什么方式解析都绕不过去，
包括现在挺流行的加密 DNS。这跟在 DNS 层过滤是两个位置，后者是能被绕过去的。

二是按域名分流。哪些走那条线路、哪些直连，可以一条条指定，
也有 65 组 5445 条常用 App 和服务的一键直连规则集（微信、支付宝、
各家银行券商、视频音乐这些）。走错线路的后果有时候挺烦人，
比如某些国内服务看你从境外来就给你降级或者干脆拒了。

三是流量看得见。哪个设备、哪些域名、拦了多少、走的哪条线，都列出来，
按日周月年分，蜂窝单独一格因为那是唯一要花钱的。

跟 Every Proxy 比，重合的部分是 HTTP、HTTPS CONNECT、SOCKS5、PAC、
接口绑定、免 root，这些两边都有。不一样的是：

    广告和追踪拦截            我有 61063 条，它没有
    域名规则分流              我有，它没有
    常用 App 一键直连规则集   我有 65 组 5445 条，它没有
    指定直连流量走哪张网      我有，它没有
    备用 DNS 并可选出口       我有，它没有
    流量统计按出口分列        我有，它没有
    实时速率和连接数          我免费，它要付费升级
    丢包率和健康诊断          我有，它没有

（依据是它官网 https://www.everyproxy.co.uk/ 和商店页公开写的功能）

它有一样我没有：SOCKS4。确实没做，暂时也不打算做。


────────────────────────────────

跑分，以及我怎么把自己坑了一次

拿 Majestic Million 前 450 个域名，两边同时跑：

    中位 TTFB       我 2.004 秒      它 2.333 秒      快 14.1%
    逐站更快        我 204 站        它 113 站
    大文件下载      我 6.17 MB/s     它 5.42 MB/s
    符号检验        z = 5.21         p < 0.0001

复杂页面差得更多，这组是用真实浏览器完整渲染测的：

    checkout.stripe.dev    我 5.3 秒     它 38.8 秒，超时
    apps.apple.com         我 10.3 秒    它 38.3 秒，超时
    github.com             我 2.1 秒     它 7.9 秒
    play.google.com        我 2.6 秒     它 13.5 秒

支付页新闻站这种要同时开几十条连接，每个第三方域都得单独走一遍
DNS、TCP、TLS，代理多一跳的成本被放大很多倍。

数字先放这。但我得说说这数是怎么来的，因为第一次测的时候我完全测错了。

最早是先把 A 跑完再跑 B，看着挺合理，结果差距大得离谱，自己都不信。
后来才想明白，上游线路的延迟一直在变，先后测出来的差里有多少是漂移根本分不清。
改成两个代理同时开着、每个域名紧挨着测两边、间隔不超过两秒，数字才稳下来。

还有个更阴的。配对里第二个被测的那方会命中手机的 DNS 缓存，白占一截便宜。
是把顺序按奇偶交换才抵消掉的，偶数域名我先测，奇数域名它先测。
后来还是不放心，又做了一轮双预热重测，两种方法结论对得上，才敢往外说。


────────────────────────────────

为什么不用现成的框架

写这篇之前把 Every Proxy 的 apk 解开看了看，它转发跑在 Netty 上。你也能自己验：

    unzip -p "Every Proxy.apk" classes*.dex | strings | grep -c "io/netty"

Netty 是好东西，服务端标杆，这没什么好争的。但它在 Android 上是另一回事。

官方那份 Requirements 页从头到尾只写 Java 6 以上运行、Java 7 以上编译，
全文没出现过 Android。仓库十四个 CI 配置，没有一个跑 Android。
    https://netty.io/wiki/requirements-for-4.x.html

更直白的是 Google 自家的 gRPC。grpc-java 的 README 里，Netty transport 那条写着
"It is not officially supported on Android"，Android 客户端一律让你换成 OkHttp。
    https://github.com/grpc/grpc-java

去年秋天还真出过事，场景跟我这个几乎一样。九月有人报 issue，说 Netty 某几个版本
在 Android 8 到 12 上启动就崩，VerifyError，原因是新引入的 VarHandle
过不了旧版 ART 的校验。那位报告者干的活正是在 App 里用 Netty 做代理。
维护者的回复我原样贴过来：他说不认为常规贡献者里有 Android 用户。
    https://github.com/netty/netty/issues/15654

这事跟我一开始的动机是一回事：依赖别人的东西，出了问题你只能等。
所以转发这块我用的是 JDK 自带的 java.nio，一行第三方网络框架都没有。

顺带说个自己的乌龙。我原本以为两边都是纯 JVM 不带原生库，写到一半才发现
自己包里有 8 个 .so，是 AndroidX 组件自带的，加起来七十来 KB。
Every Proxy 反而一个都没有，这项它比我干净，差点就写反了。


────────────────────────────────

协程这块，可能是我最想聊的

Android 官方对协程什么态度，原话可以直接查：

    Coroutines is our recommended solution for asynchronous programming on Android.
    https://developer.android.com/kotlin/coroutines

不过官方推荐是生态和 API 层面的，跟运行时快不快是两码事，别混。

协程真正帮到我的是：线程数不跟着连接数长。

最早我写得很笨，一条隧道开两个阻塞线程。128 条连接就是 256 个线程，然后就崩了。
后来改成 NIO reactor，selector 线程按 CPU 核数算、最多 4 个。
真机上并发峰值到过 107 条连接，selector 还是那 2 到 4 个，一动不动。

现在一条客户端连接就是一个协程，从进门到关闭是一段顺着往下读的代码：

    解析目标 → 规则判定 → DNS → 选出口 → 建 TCP → 回握手 → 转发直到结束

七步就是七行，哪一步要限时就用 withTimeoutOrNull 包一层。换成回调式写法，
这七步得拆成好几段，错误处理和超时在每段各写一遍。

最麻烦的是取消。客户端一断，你得知道现在走到哪了、哪些资源要回滚。
协程这边是自动级联的，协程一取消，隧道拆掉、两端关掉、连接数名额释放，
不用手写那个状态机。而那个状态机恰恰是这类程序最容易漏分支的地方，
漏一条就是一个 FD （File Descriptor ）泄漏，还特别难查。

还有个意外收获。因为一条请求就是一个协程作用域，追踪信息能顺着它一路传下去，
规则判定、DNS 从哪来、真正连到哪个 IP、失败卡在哪步、隧道为什么关，
全能用同一个 id 串起来。就靠这套东西，我后来删掉了三个自己以前加错的机制，
因为终于能用数据判断它们到底有没有用，而不是凭感觉。

七月 Google 发过一篇《How R8 made Kotlin Coroutines on Android 2x faster》，
R8 把 Atomic 字段更新器优化成 Unsafe 变体，协程的启动和取消最高快两倍。
这个我跟着吃到了。
    https://android-developers.googl ... ines-2x-faster.html


────────────────────────────────

IPv6 是最近才补上的，顺手记个坑

之前只有出站能走 v6，入站一直连不上。我一直以为是接口扫描那行把 v6 地址过滤掉了，
心想删掉不就完了。

真去查才发现想简单了。准入用的网段表是 32 位整数存的，v6 是 128 位，压根塞不进去。
就算放行扫描也没用，网段根本进不了准入集。改成按字节比前缀之后才两边都通，
v4 和 v6 靠地址长度天然分开，不会互相误放行。

顺手还改了个显示问题。v6 地址进 URL 得加方括号，不然 fd00::1:8090 这种是非法的，
冒号既是地址的一部分又是端口分隔符。现在界面上直接显示成带括号的样子，
省得有人照着填出错。

模拟器上验过：接口列表里 v6 和 v4 一起出现，准入集两个都收，
经 v6 发过去的请求该回 400 回 400，CONNECT 到回环地址照样被出口护栏拦住。


────────────────────────────────
先说这个app的起因。
Android 17 推送那天，我手机升完，Every Proxy 就不能共享了。别的设备连不上，
不报错，就是连不通。查了一圈才知道是系统新加了一个本地网络权限
ACCESS_LOCAL_NETWORK，targetSdk 到 37 的应用，做任何局域网通信之前都得先申请它。
没申请的话，LAN 流量直接失败，而且不崩溃、不报错，就是静悄悄地不通。
    https://developer.android.com/pr ... -network-permission

代理这类软件整个业务就在局域网上，这一刀正好砍在命门。Every Proxy 当时没跟上，
我就那么被卡住了。

其实在那之前我就攒了一肚子火。用它的过程中碰到过好几个问题，
换网之后要重启才恢复、某些域名偶尔连不上之类的，但代码不是我的，
我除了等更新什么也做不了。

那天干脆自己动手写了一个。


────────────────────────────────

这东西到底解决什么问题

Pixel 7 以后的机器自带一项 Google 魔法服务，官方说明在这：
    https://support.google.com/pixelphone/answer/2819573

好用是好用，但它只保护手机自己。你家电视、Switch、iPad、笔记本，一个都沾不上。
这些设备要么没地方配，要么配了也没用。

想让它们也走上那条线路，流量就必须先进到手机里，再由手机发出去。
而且必须经过一个 App，直接开热点是不行的，热点那条路是内核转发的，
数据包压根不经过任何应用，也就跟你手机上装了什么服务没关系。

所以这个 App 干的事很简单：在手机上监听一个端口，别的设备把它当代理，
流量进来之后由这个 App 转出去，走的就是手机上选定的那条线路。
其他设备什么都不用装，填个地址就完事。


那你会问了，路由器不能干这事吗？答案是不能

规则、广告拦截、流量统计，这些路由器全都能干，而且 pi-hole、AdGuard Home
这些方案比我成熟得多，我一点不否认。

但路由器拿不到 Google 魔法服务。那东西绑在 Pixel 上，只有手机自己能用。
你在路由器上写再多规则，电视的流量也走不上那条线。

这就是这个 App 唯一不可替代的地方。没有这层共享，我这东西确实没什么存在的必要。
所以受众也很明确：手上得是 Pixel 7 或更新的机器。不是这个机型，
最大的那个用处就没了，剩下的功能路由器都能替你干。


────────────────────────────────

既然流量都从这过了，顺手做的几件事

流量已经经过这一跳了，不做点什么也是浪费。

一是广告和追踪拦截，内置 61063 条。这块有个细节挺多人不知道：
我是在拿到目标域名之后、去查地址之前做的判断。HTTPS 的 CONNECT 请求
按协议必须明文带上目标域名，所以客户端拿什么方式解析都绕不过去，
包括现在挺流行的加密 DNS。这跟在 DNS 层过滤是两个位置，后者是能被绕过去的。

二是按域名分流。哪些走那条线路、哪些直连，可以一条条指定，
也有 65 组 5445 条常用 App 和服务的一键直连规则集（微信、支付宝、
各家银行券商、视频音乐这些）。走错线路的后果有时候挺烦人，
比如某些国内服务看你从境外来就给你降级或者干脆拒了。

三是流量看得见。哪个设备、哪些域名、拦了多少、走的哪条线，都列出来，
按日周月年分，蜂窝单独一格因为那是唯一要花钱的。

跟 Every Proxy 比，重合的部分是 HTTP、HTTPS CONNECT、SOCKS5、PAC、
接口绑定、免 root，这些两边都有。不一样的是：

    广告和追踪拦截            我有 61063 条，它没有
    域名规则分流              我有，它没有
    常用 App 一键直连规则集   我有 65 组 5445 条，它没有
    指定直连流量走哪张网      我有，它没有
    备用 DNS 并可选出口       我有，它没有
    流量统计按出口分列        我有，它没有
    实时速率和连接数          我免费，它要付费升级
    丢包率和健康诊断          我有，它没有

（依据是它官网 https://www.everyproxy.co.uk/ 和商店页公开写的功能）

它有一样我没有：SOCKS4。确实没做，暂时也不打算做。


────────────────────────────────

跑分，以及我怎么把自己坑了一次

拿 Majestic Million 前 450 个域名，两边同时跑：

    中位 TTFB       我 2.004 秒      它 2.333 秒      快 14.1%
    逐站更快        我 204 站        它 113 站
    大文件下载      我 6.17 MB/s     它 5.42 MB/s
    符号检验        z = 5.21         p < 0.0001

复杂页面差得更多，这组是用真实浏览器完整渲染测的：

    checkout.stripe.dev    我 5.3 秒     它 38.8 秒，超时
    apps.apple.com         我 10.3 秒    它 38.3 秒，超时
    github.com             我 2.1 秒     它 7.9 秒
    play.google.com        我 2.6 秒     它 13.5 秒

支付页新闻站这种要同时开几十条连接，每个第三方域都得单独走一遍
DNS、TCP、TLS，代理多一跳的成本被放大很多倍。

数字先放这。但我得说说这数是怎么来的，因为第一次测的时候我完全测错了。

最早是先把 A 跑完再跑 B，看着挺合理，结果差距大得离谱，自己都不信。
后来才想明白，上游线路的延迟一直在变，先后测出来的差里有多少是漂移根本分不清。
改成两个代理同时开着、每个域名紧挨着测两边、间隔不超过两秒，数字才稳下来。

还有个更阴的。配对里第二个被测的那方会命中手机的 DNS 缓存，白占一截便宜。
是把顺序按奇偶交换才抵消掉的，偶数域名我先测，奇数域名它先测。
后来还是不放心，又做了一轮双预热重测，两种方法结论对得上，才敢往外说。


────────────────────────────────

为什么不用现成的框架

写这篇之前把 Every Proxy 的 apk 解开看了看，它转发跑在 Netty 上。你也能自己验：

    unzip -p "Every Proxy.apk" classes*.dex | strings | grep -c "io/netty"

Netty 是好东西，服务端标杆，这没什么好争的。但它在 Android 上是另一回事。

官方那份 Requirements 页从头到尾只写 Java 6 以上运行、Java 7 以上编译，
全文没出现过 Android。仓库十四个 CI 配置，没有一个跑 Android。
    https://netty.io/wiki/requirements-for-4.x.html

更直白的是 Google 自家的 gRPC。grpc-java 的 README 里，Netty transport 那条写着
"It is not officially supported on Android"，Android 客户端一律让你换成 OkHttp。
    https://github.com/grpc/grpc-java

去年秋天还真出过事，场景跟我这个几乎一样。九月有人报 issue，说 Netty 某几个版本
在 Android 8 到 12 上启动就崩，VerifyError，原因是新引入的 VarHandle
过不了旧版 ART 的校验。那位报告者干的活正是在 App 里用 Netty 做代理。
维护者的回复我原样贴过来：他说不认为常规贡献者里有 Android 用户。
    https://github.com/netty/netty/issues/15654

这事跟我一开始的动机是一回事：依赖别人的东西，出了问题你只能等。
所以转发这块我用的是 JDK 自带的 java.nio，一行第三方网络框架都没有。

顺带说个自己的乌龙。我原本以为两边都是纯 JVM 不带原生库，写到一半才发现
自己包里有 8 个 .so，是 AndroidX 组件自带的，加起来七十来 KB。
Every Proxy 反而一个都没有，这项它比我干净，差点就写反了。


────────────────────────────────

协程这块，可能是我最想聊的

Android 官方对协程什么态度，原话可以直接查：

    Coroutines is our recommended solution for asynchronous programming on Android.
    https://developer.android.com/kotlin/coroutines

不过官方推荐是生态和 API 层面的，跟运行时快不快是两码事，别混。

协程真正帮到我的是：线程数不跟着连接数长。

最早我写得很笨，一条隧道开两个阻塞线程。128 条连接就是 256 个线程，然后就崩了。
后来改成 NIO reactor，selector 线程按 CPU 核数算、最多 4 个。
真机上并发峰值到过 107 条连接，selector 还是那 2 到 4 个，一动不动。

现在一条客户端连接就是一个协程，从进门到关闭是一段顺着往下读的代码：

    解析目标 → 规则判定 → DNS → 选出口 → 建 TCP → 回握手 → 转发直到结束

七步就是七行，哪一步要限时就用 withTimeoutOrNull 包一层。换成回调式写法，
这七步得拆成好几段，错误处理和超时在每段各写一遍。

最麻烦的是取消。客户端一断，你得知道现在走到哪了、哪些资源要回滚。
协程这边是自动级联的，协程一取消，隧道拆掉、两端关掉、连接数名额释放，
不用手写那个状态机。而那个状态机恰恰是这类程序最容易漏分支的地方，
漏一条就是一个 FD （File Descriptor ）泄漏，还特别难查。

还有个意外收获。因为一条请求就是一个协程作用域，追踪信息能顺着它一路传下去，
规则判定、DNS 从哪来、真正连到哪个 IP、失败卡在哪步、隧道为什么关，
全能用同一个 id 串起来。就靠这套东西，我后来删掉了三个自己以前加错的机制，
因为终于能用数据判断它们到底有没有用，而不是凭感觉。

七月 Google 发过一篇《How R8 made Kotlin Coroutines on Android 2x faster》，
R8 把 Atomic 字段更新器优化成 Unsafe 变体，协程的启动和取消最高快两倍。
这个我跟着吃到了。
    https://android-developers.googl ... ines-2x-faster.html


────────────────────────────────

IPv6 是最近才补上的，顺手记个坑

之前只有出站能走 v6，入站一直连不上。我一直以为是接口扫描那行把 v6 地址过滤掉了，
心想删掉不就完了。

真去查才发现想简单了。准入用的网段表是 32 位整数存的，v6 是 128 位，压根塞不进去。
就算放行扫描也没用，网段根本进不了准入集。改成按字节比前缀之后才两边都通，
v4 和 v6 靠地址长度天然分开，不会互相误放行。

顺手还改了个显示问题。v6 地址进 URL 得加方括号，不然 fd00::1:8090 这种是非法的，
冒号既是地址的一部分又是端口分隔符。现在界面上直接显示成带括号的样子，
省得有人照着填出错。

模拟器上验过：接口列表里 v6 和 v4 一起出现，准入集两个都收，
经 v6 发过去的请求该回 400 回 400，CONNECT 到回环地址照样被出口护栏拦住。


────────────────────────────────

谁适合折腾这个

首先得是 Pixel 7 或更新的机器，这是前提。上面说了，没有那层共享，
这个 App 最大的用处就不存在了。

然后是需要高强度用这个服务的机器，比如我自己高强度用的 macbook pro 2021


────────────────────────────────

项目地址 https://github.com/wresource/hxmy-proxy
Android 10 以上，免费，没有内购，不用注册，不传任何数据上去。
坑踩了一堆，欢迎来提 issue 骂我。


谁适合折腾这个

首先得是 Pixel 7 或更新的机器，这是前提。上面说了，没有那层共享，
这个 App 最大的用处就不存在了。

然后是需要高强度用这个服务的机器，比如我自己高强度用的 macbook pro 2021


────────────────────────────────

项目地址 https://github.com/wresource/hxmy-proxy
Android 10 以上，免费，没有内购，不用注册，不传任何数据上去。
坑踩了一堆，欢迎来提 issue 骂我。

我不喜欢 play store 的一点是它把开发者的住址都写在网页里了

HelloWorld 发表于 2026-8-15 16:54
我不喜欢 play store 的一点是它把开发者的住址都写在网页里了

哈哈哈哈哈哈，等等apple store居然没有，不过有名字，我这个是公共场所的地址，问题不是很大

wresource 发表于 2026-8-15 16:58
哈哈哈哈哈哈，等等apple store居然没有，不过有名字，我这个是公共场所的地址，问题不是很大 ...

那还好

HelloWorld 发表于 2026-8-15 18:08
那还好

论坛怎么不支持markdown渲染啊，感觉不太好发

wresource 发表于 2026-8-16 01:32
论坛怎么不支持markdown渲染啊，感觉不太好发

估计得改源码

终于解决了我的一个疑问。此前一直用every proxy来共享pixel vpn的，突然有一天，无论如何都不成功，已经放弃。今天看到你的这个app，试了一下，的确能够用。另外，还顺带解决了另一个问题：我有一张美国的手机卡，可以漫游，但无法开热点，这样就可以绕过限制了。github已star！