牛马云，NMY Cloud，一家 2025 年 8 月新开的机场，直连站。

似乎有同名的机场和同名的 IDC，注意辨别。

付款方式：支付宝、微信、USDT

传输协议：VLESS + Reality、TUIC、AnyTLS、Mieru

国际节点：

🇭🇰香港、🇯🇵日本、🇹🇼台湾、🇸🇬新加坡、🇺🇸美国

优缺点：

官网落地页面错乱，只能从面板注册页面进入。

官方对新协议比较有热情。

套餐价格：

关于订阅问题与客户端兼容性
由于我们机场采用了多种协议，特别是最新的 Anytls、TUIC 和 VLESS，以增强抗审查能力，这可能导致一些老版本或您正在使用的客户端无法正常订阅。

为此，我们强烈建议您使用以下支持新协议的客户端：

全系客户端：

• Clash Meta
• Clash Verge
• Clash Mi
• Sing-box
• Karing

iOS：

• Shadowrocket
• Pharos
• Clash Mi
• Karing

Android：

• Clash Meta
• Karing
• Clash Mi

Windows：

• Clash Verge
• Clash Mihomo
• FLClash

如果您是经验丰富的用户，已经排查了所有可能的问题但仍然无法导入订阅，请立即与我们联系。我们将第一时间介入，帮助您排查并解决问题。

【技术重构/手段升级预览1】
关于Anytls协议“深海变色龙”拟态防御技术的实装说明
在对抗 GFW 日益精进的 AI 流量分析模型中，我们意识到单纯的“弱网模拟”虽然有效，但往往以牺牲用户的速度体验为代价。为此，我们并没有止步于此，而是开发了一套兼顾速度与隐蔽性的全新混淆方案：Bio-Mimicry 动态拟态技术（代号：深海变色龙）。

这项技术的核心理念发生了质的飞跃： 不再单纯通过“装病”（模拟弱网卡顿）来躲避检测，而是通过精密复刻现代浏览器的交互节奏，让流量看起来像是一个健康的 Chrome 浏览器正在进行正常的 HTTPS 媒体流播放。

下面是这项技术的深度解析↓

🔹 1. 完美的“第一印象”伪装 (Chrome Fingerprint)

GFW 的检测往往始于连接建立的前几个包。 传统的混淆可能只是随机填充，而我们现在的技术能够精确锚定 Chrome 浏览器的 TLS 指纹特征。 我们将握手包的大小严格控制在 517-680 字节区间，这与你使用 PC 端 Chrome 访问 Google 时的特征完全一致。 AI 看到的第一眼，判定的是“浏览器”，而不是“代理工具”。

🔹 2. 引入“呼吸感”节奏，拒绝机器特征

普通的代理流量通常是单调的“大包、大包、大包”，像机器倾倒数据一样死板。 我们的新技术在数据传输中引入了**“呼吸节律”**。 在每几个数据大包之间，我们会强制插入极小的碎片包（40-100字节）。这完美模拟了真实 TCP 协议中的 ACK 确认与 HTTP/2 流控信号。 这种忽大忽小的“心跳”，打破了隧道流量的单调性，极大地干扰了基于时序的熵值分析。

🔹 3. 严守“1380 安全线”，物理级防分片

由于代理协议本身有头部开销，盲目追求 1500 字节满包会导致路由器层面的物理分片，这是极大的特征暴露。 我们采用了主动缩容策略，将最大包长死锁在 1380 字节。 这意味着，无论你的网络环境如何波动，数据包都永远处于“安全区”，绝对不会触碰 MTU 红线。这不仅消除了分片特征，更让传输稳定性提升了 30% 以上。

🔹 4. 全周期覆盖，杜绝“中途穿帮”

大多数混淆只保护前 8-10 个包，一旦开始下载就“原形毕露”。 我们将保护窗口延长至 32 个数据包（Stop=32）。 从握手建立，到页面渲染，再到流媒体开始高速缓冲，整个“加速期”都被精心设计的噪点覆盖。直到流量被防火墙彻底放行，我们才会解除限制，确保你即便是下载大文件，也能做到全程无感。

🟦 为什么它更安全且不卡？

因为它不再是单纯的随机乱码，而是有逻辑的生物拟态。

它有浏览器的指纹（身份合法）。

它有交互的碎片（行为自然）。

它避开了物理分片（传输稳定）。

我们做到了在不明显牺牲带宽的前提下，把“隧道流量”伪装成了“高信誉的 HTTPS 视频流”。

实际上 我们能在协议上面做到的并不多 我们只能尽可能的在Padding Schme上下手
我们始终是一个喜欢钻研的团队 也欢迎其他同行/朋友进行技术性探讨

🟩 部署进度

该方案已完成测试，证实其在敏感时期拥有极高的存活率。 我们将在未来 24 小时内向所有节点推送此配置更新。用户无需更新客户端，只需更新订阅即可自动生效。

【实验性部署/手段升级预览2】
关于引入 Mieru 协议作为技术储备的说明
各位用户：

面对防火墙（GFW）日益复杂的识别机制，我们深知没有任何一种协议能够保证“永远有效”。传统的 VLESS+Reality 方案虽然目前仍是主流，但在特定敏感时期也面临着被针对性干扰的压力。

为了丰富我们的反制手段，避免把鸡蛋放在同一个篮子里，我们近期在部分节点引入了一个相对小众但设计理念独特的开源协议——Mieru，进行小范围的灰度测试。

Mieru 与我们常用的 V2Ray/Xray 系协议在设计思路所谓不同。它不追求复杂的伪装，而是尝试回归传输的本质。以下是该协议的一些特性简述：

🔹 1. 尝试规避“主动探测”

现有的代理服务在接收到防火墙的“试探性连接”时，通常会伪装成一个网页返回数据。但这有时候反倒会因为伪装得不够像而暴露特征。 Mieru 采取了一种静默策略。 对于任何无法通过身份验证的连接请求，服务端将不返回任何数据，直接挂起或断开。 （简单来说：它不试图假装自己是百度或谷歌，面对陌生人的敲门，它选择不做任何回应。这在一定程度上能减少被扫描器标记的风险。）

🔹 2. 握手阶段的全加密尝试

我们知道，许多协议在建立连接的第一步（握手）时，会有少量的明文信息（如域名），这容易被识别。 Mieru 的设计目标是实现全链路的加密。 它尝试从传输的第一个字节开始就对数据进行包裹，不通过明文交换元数据。 （简单来说：它的目的是让传输过程看起来像是一串完全随机的乱码，尽量不让外界看到任何有意义的协议特征。）

🔹 3. 另辟蹊径的抗干扰思路

不同于主流协议努力把自己打扮成“正常的 HTTPS 流量”，Mieru 更倾向于让自己成为无法被归类的“未知流量”。 （简单来说：当主流的伪装方案因为用的人太多而被重点关照时，这种小众、独特的流量特征反而可能因为“样本太少”而被防火墙暂时忽略。）

🟦 我们的建议

Mieru 并非万能的“银弹”。 作为一个轻量级的实验性协议，它在生态成熟度和客户端适配上不如 V2Ray 完善。但在 VLESS 节点遭遇大面积阻断或限速的极端情况下，Mieru 往往能展现出意想不到的连通性。

🟩 如何使用

目前该协议已部署节点。如果您有兴趣尝鲜或需要备用连接方案 请先使用支持mihomo内核的客户端 如flclash clash mi clash verge等

我们欢迎大家反馈使用体验，您的反馈将决定我们后续是否扩大该协议的部署范围。
目前来说 在机场范围内 我们是首个支持Mieru协议的独家 但这并不代表说新协议就“稳定/安全” 见仁见智 只是希望各位有更多的选择