那肯定，但就算要查手机肯定也是优先查手机上应用列表读取到翻墙软件的😁

pqc这些安全升级...比优化现实上门维度更可控更直接。
这不就和自建机房需要考虑水电网和硬件老化，但是买云服务不需要考虑基础设施一样...不是一个维护的🙈

但运营商app内置个读应用列表的功能真的一点成本都没有（

致敬传奇xray GUI中国电信

✅ Group video description display turned off

这个账号甚至还推荐过匿名聊天软件（

叫simple x（

آقا به نظر میاد XDNS کار میکنه

Yes,for now i can only access internet with dns tunnels

About a month ago, when Iran experienced serious disruptions in Internet access, the XTLS team closely monitored the situation and collected data on methods that were actually effective in bypassing the restrictions.

The analysis showed that in aggressive network environments, the solutions we normally rely on are sometimes insufficient for maintaining stable connectivity. In a number of cases, additional obfuscation mechanisms were required, for example mimicking DNS traffic, ICMP, or other protocols permitted within the country.

At that time, implementing new obfuscation methods directly in the core was an extremely labor-intensive process. For instance, disguising traffic as DNS or ICMP would have effectively required implementing a full-fledged transport protocol from scratch.

As a result, the idea was proposed to completely decouple data delivery from packet obfuscation, and a new concept called finalmask was introduced into the core.

The final masking layer represents the lowest, unreliable layer. For UDP, it only performs per-packet obfuscation and does not provide reliable delivery. Reliability is handled by the upper layer.

The responsibility model can now be structured as follows:

Protocol: encryption and authentication.
Transport: fragmentation, retransmission, and congestion control.
Finalmask: a stack of stateless masks that sequentially wrap the packet before transmission.

For clarity, we need to distinguish between several key concepts:

header-: simply attaches a fake header to a packet.
x: actually encapsulates and transmits data through the structure of the target protocol.

xDNS: allows traffic to be tunneled inside legitimate DNS queries.

Since it is an X* protocol, xDNS generates fully standards-compliant packets.

Its implementation is straightforward.

Client side:
The data stream is split into small chunks and encoded. These chunks are then divided into 63-byte labels and assembled into an FQDN of the form:

[N].[N+1].[domain]

The result is encoded in DNS wire format.

Server side:
The server extracts the data and packs the response into a TXT answer record.

最近公司里不少用cursor的，但是cursor在国内只能用那几个垃圾模型，我就想在vps上弄个转发程序，转发一下api2.cursor.sh。然后我突然想到，reality不就对外表现成端口转发吗？直接reality偷api2.cursor.sh，再改一下本机hosts，果然就能用opus4.6了。给了几个同事一块用，正好可以骗骗公司的流量审计，以后正大光明的用reality翻墙

💬 New comment on Xray-core#5581 Geodat: Reduce peak memory usage
by @RPRX

感谢 @fortuna 提供有价值的参考资料，伊朗的民间互联网出境被完全切断时，只能依赖 DNSTT、XDNS 这类基于真实 DNS TXT 查询的隧道（利用了运营商自用的互联网出境线路），若商用互联网出境未被切断，则还可以使用 XHTTP 加境内 CDN

XDRIVE 要等伊朗的民间互联网开放了一些网站才能用，一个月前开放的是 Google、OpenAI 等，或者如果能从境外访问到伊朗境内的商用互联网，理论上也可以利用境内的网盘、付费存储等服务，[或者自己搭个 FTPS，境内 VPS 上并不存在 Xray](https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3980000253)

我觉得 XDRIVE 在技术上不存在大问题（即使是利用 ChatGPT 中转），而是免费服务商可能的封禁，当然如果是付费的比如阿里云 OSS 等兼容 S3 的存储服务则不会以“超过频率”这一理由拒绝提供服务，而是境内的服务商可能会配合 GFW 试图封它

比较有趣的一点是 XDRIVE 被设计为使用 Xray 的通用 TLS 设置以支持 domain fronting，https://github.com/XTLS/Xray-core/pull/5645#issuecomment-3851839033 提到的给 www.googleapis.com 发 www.google.com 的 SNI 其实可能会导致返回默认证书，这种情况可以用 verifyPeerCertByName

Reply to this message to post a comment on GitHub.

The XTLS team, once again living up to the slogan “penetrates everywhere,” has indeed integrated several new tools into the core based on the previously described FinalMask mechanism.

In particular, this refers to xDNS and xICMP.

xDNS allows us to proxy traffic inside legitimate DNS queries.

xICMP allows traffic to be proxied inside ICMP (ping) packets

Configuration examples can be found here:

https://github.com/XTLS/Xray-core/pull/5633

https://github.com/XTLS/Xray-core/pull/5560

https://xtls.github.io/config/transport.html#finalmaskobject

P.S. If you are a developer of a client application or a management panel, please note that because masks can now be stacked and their structure has become more complex, the standard vless:// link format has been updated. Parameters are now passed as a URL-encoded JSON object via the &fm= key.

💬 New comment on BBS#19 从双重标准到“大新闻”：浅谈代理协议设计与实现上的一些本质问题与优先级区别
by @RPRX

最近隔壁称 NaiveProxy 是 TLS 代理抵抗流量监测的最优解，**我觉得吧首先它不能较为隐蔽地穿透 SNI 白名单**，毕竟即使是中国都已经有泉州等地区出现了 SNI 白名单（当然可以改代码把它的 TLS 改成 REALITY，~~或者说没有证据表明 GFW 会主动探测并校验证书的真实性~~），**其次若以浏览器行为为基准，浏览器浏览网页基本上都是 GET、POST 而不是 CONNECT，后者也无法穿透几乎所有 CDN**（~~当然这个也可以改~~），在这两点上不如 XHTTP + Browser Dialer，**另外 Browser Dialer 有一个重要特性是它用的就是本地常用浏览器，流量完美融入其中，不只是 Chrome 还可以是 Firefox 等，还可以实现版本特征上的多样分布，也不用 Chromium 每发一个版本都去改一次代码、发个版本，以及 Chrome 略不同于 Chromium，比如会产生些 Google 请求，综上我认为 XHTTP + Browser Dialer 更优**

关于最后一点我多解释下，大概是几年前我在 Project X 群组说过，你用着“Chrome”浏览器疯狂上外网，这是正在被 GFW 观测到的，**然而你却没产生一丁点“非法”的 Google 痕迹，比如尝试查询 DNS 或尝试 TLS 握手，~~这对吗这合适吗用脚趾想都能猜到是咋回事~~**

Reply to this message to post a comment on GitHub.

💬 New comment on BBS#19 从双重标准到“大新闻”：浅谈代理协议设计与实现上的一些本质问题与优先级区别
by @RPRX

> Browser Dialer 可以通过自建 DoH + 配置浏览器强制 ECH #13 (comment)
>
> 如果是过CDN，可以找LLM写个脚本，通过 xray api 在 balance 下轮换 outbound，XMUX maxConnections 填 1，outbound 的 IP 根据 CDN IP 池随机生成，保持随机数量的连接

Browser Dialer 的话 XMUX 会失效，完全取决于浏览器自己的策略，**不过上下行分离还是能控制的**，说起来忘提上下行分离了，简单说一下：被代理的流量固有的内层特征（比如 TLS in TLS）被较为精准地识别基本上都要基于来回的时序+长度特征，比如我写的那个 Trojan-killer 就是这样，而如果只有单向的特征那基本上无法精准，尤其是反方向还有 response/request header 和 h2/h3 小帧捣乱，几个月前某群组中有人自称是新疆某大学的校园网负责人，~~他拿 Xray 来搭整校翻墙线路~~，他说“GFW 说对于上下行分离暂时没有办法”

这不比 NaiveProxy 再怎么 padding 更有用吗，虽然 XHTTP 也有可自定义的往返 header padding，而 body padding 策略则取决于 VLESS Flow，当然了“暂时没有办法”不等于永远没有办法，比如即使你下行是域名 A + TLSv1.3 + IPv4、上行是域名 B + QUIC + IPv6，你本地只有一个家庭网络的话还是都会走它，~~虽然你其实可以拿属于另一个运营商的手机流量跑上行，反正也不会产生多少流量~~

~~计划中 XHTTP 和 XDRIVE 的上下行分离可以互通，敬请期待，再往后假如哪天太闲了会给 VLESS 自身也加一个~~

> Gemini 3.1说: 轮换时间间隔根据浏览网页的行为采用泊松分布（Poisson distribution），随机在 5 分钟到 45 分钟之间波动。甚至保持当前时区的作息特点在凌晨模拟几小时的绝对“断网空闲”期。
>
> ~太逼真了~

说到“轮换时间间隔”，现有代理使用习惯的 24h 挂着同一外网那当然很假，也算是和刚刚说的 Google 问题一样能从行为模式上高度怀疑你，以前还能拿 IPv4 狡辩一下但现在各种省墙啥的，运营商早就被 GFW 深度绑定、分摊任务了，正好群里刚还有人说透明代理用 Browser Dialer 麻烦，~~不是你都这样挂着了那还是别搞太复杂的折磨自己了，直接 Vision 1:1 拉起来算了也别限制连接数啥的了~~

但真实情况就是这样，GFW 允许的话即使是 IPv6 你也拉连接数、对自己的体验好点，不允许的话（比如俄罗斯小规模试点过）你就 XHTTP XMUX / Browser Dialer，总之开发翻墙协议是这样的，我说了特征问题是永无止境的，你只能先解决过于扎眼的以及 GFW 真的拿来封你的特征（比如 TLS in TLS），剩下的再跟 GFW 慢慢拉锯~~直到它掀桌子~~，[平时多关注些更为客观的加解密问题比啥都强](https://t.me/projectXtls/1091)

~~还是得狠狠感恩中国有科研、经济等需求，顺带着让那些被拿到 SS 密码解密也无所谓的能翻出去看黄吧，别哪天忘了这茬随口键政~~

Reply to this message to post a comment on GitHub.