Фильтр публикаций


团结?你指的是这些年来隔壁的小圈子基于屁股,不是当世界警察碰瓷 Xray,就是鸡蛋里挑骨头找茬诋毁 Xray 吗?

进步?你指的是他们非但不为翻墙创造新的范式反而说 Xray 这边的努力是炒作、滥用什么的,还是他们不仅觉得 Xray 的那些安全策略没必要反而又发篇小作文妄想搞臭 Xray 吗?

那也就只剩互怼了,不过想看回应文章的可以先歇歇了,现在没空,谁像那傻逼那么闲小作文一篇接一篇,等下月初发版前再写

7.1k 21 24 42 117

但本来就是以吵架为出发点呀


你没发现中文圈干啥最后都是吵架吗


跟垃圾能团结出什么,粘鼠板吗,哈哈哈哈哈


团结起来为翻墙更进步不好吗?互怼又显示不出啥技术水准


有些人创造不了啥,找茬倒是专业的,但没意义啊,喷一道菜不好吃很容易,但做菜难啊😂


用了一下exclave,主动放弃这个傻逼软件了,乏善可陈


听说 dyhkwong 这傻逼又开始犯贱了


💬 New comment on Xray-core#6823 feat(dns): add Lua scripting for DNS queries
by @RPRX

NEXT 架构大概是组件可任意串联,尤其是哪里都能塞路由/DNS,以及增强匹配/行为语法(比如这个 lua),~~最好还能判断/修改一些内部变量~~,以及配置文件和 API 改为一行行加载脚本的形式而不是现在这种固定 JSON 加 gRPC API,~~貌似应当全用 lua~~

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6834 Suppress outer CloseNotify for XTLS
by @RPRX

似乎同时又解决了一个特征问题(两个 CloseNotify)

~~至于有些 TLS 实现最后可能没发 CloseNotify 倒没事,TCP 本就可能会提前断~~

目前最大的特征还是 max record size 问题(虽然合乎 TLSv1.3 的规范但),这个最好靠 geo 分流到服务端多 IP 来解决

但也确实没有“双重加密”产生的那些问题,另外至少不是纯 8k 了,但若把 buf.Size 改成 16k,又会影响有传输层时的 size 特征

还有开很多 TCP 连接的问题,但好处是没有任何“队头阻塞”问题,所以都有利有弊吧,**用户应按实际需求选择代理方式组合**

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6821 Geodata: Reduce MPH matcher runtime memory usage
by @RPRX

> on Loyalsoldier's geosite.dat category-ads-all now retains 14.4 MiB in under 300 objects instead of 32.2 MiB in 636k, and with ads-all, cn and geolocation-!cn loaded a forced GC takes 0.3 ms instead of 9-10 ms at GOMAXPROCS=2. build time and lookups on these lists are the same, the new differential test compares against a map over all short inputs

~~这个 PR 很猛啊~~

事实上对于索引 Geodata 这种常驻内存的静态数据集,本来就应该这么设计,在“decompress 程度”和"索引速度"间找个平衡点

~~所以其实我感觉还能进一步降低内存占用~~

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6797 XHTTP: xmux.maxConnections is ineffective in Go 1.27 builds (v26.9.8+, main) — one TCP connection per session while TLS handshakes hang, leading to OOM
by @RPRX

~~这下又成 release-blocker 了,不过说不定这两天先再发个 pre-release 测测最近的 commits 有没有 bug~~

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6454 tun模式存在dns泄漏
by @RPRX

https://github.com/XTLS/Xray-core/pull/6773 Linux 已解决问题,加了个新配置项 `autoSystemDNS`,我感觉改到 gateway 这方法也适用于 FreeBSD,@drTr0jan @brookwko 你们试试

这个 issue 上面的讨论已确认 Windows 上改所有网卡的 DNS 也可行,~~等个有缘人 PR,或许只有 macOS 不行~~

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6844 Proxy: Add MASQUE inbound (IETF CONNECT-IP server, RFC 9484)
by @RPRX

@CluvexStudio 给你个任务,参考 AWG 小改一下 WG、加些配置项,另外若 GitHub 允许的话,参考你提到的 Aether 小改一下 MASQUE https://github.com/XTLS/Xray-core/pull/6810#issuecomment-5842441136 、加些配置项,前者适用于俄罗斯、后者适用于伊朗,完成后给你转一个 Project X NFT

Reply to this message to post a comment on GitHub.


💬 New comment on BBS#44 墙的倒掉,已经进入按天的倒计时?
by @RPRX

> 但是从一个开发突破信息封锁工具的开发者口中说出来还是略感失望,尤其是在rprx口中说出来。

首先信息封锁并非只是某些国家的问题,事实是全世界都在建墙,只是有墙高墙低之分,我也不觉得我开发个这种工具就必须要站哪个阵营

其次既然你知道是我,那么你没考虑到的一点是,以我的身份也并不应当偏向谁,~~怎么你是想让我人间蒸发还是失去潜在的庇护?~~

最后不要试图把我拉入任何的现实政治纷争中,我既没兴趣也不应当掺和,这个世界并非没有人种之分,且谁都想当天龙人,多的不说了

Reply to this message to post a comment on GitHub.


🔌 New pull request Xray-core#6831 SS2022
by: @Fangliding

移除GPL的sing-ss依赖以及伴生的sing-bride

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6810 MASQUE transport: Add HTTP/2 (Extended CONNECT, RFC 8441)
by @RPRX

简单看了下代码,对 h2 而言 Chrome 指纹是 default(但 https://github.com/XTLS/Xray-core/pull/6807 的 h3 默认没开 ChromeParrot,~~没看能不能开~~),h2、h3 都默认不发 Chrome UA(这点与 XHTTP 以及 Xray-core 里其它 HTTP 请求相反)但支持那些特殊值,不过对于这些我暂不确定哪种默认值对 MASQUE 最合适所以等更多反馈后再调整,ALPN 决定 h2/h3 的逻辑也与 XHTTP 相反,毕竟 MASQUE 主场是 h3

说起来对于 XDRIVE 我还没细看指纹和 UA,设想是与 XHTTP 对齐吧,另外 MASQUE 似乎也能引入 XMUX https://github.com/XTLS/Xray-core/pull/6748#issuecomment-5752780799

~~至于 WARP,如果其它仓库明确兼容它且没被 DMCA 的话也不是不能支持,Aether 也可以参考,AWG 也是 https://github.com/XTLS/Xray-core/issues/6710#issuecomment-5575450166~~

Reply to this message to post a comment on GitHub.


💬 New comment on Xray-core#6828 Burst observatory: Cancel pending HTTP checks
by @RPRX

~~搞得我开始怀疑是不是有人给 AI 下达了自动给 Xray PR 的指令~~

这三个 Burst observatory 的 PR 先合为一个吧不然有点刷屏,~~XHTTP 的那俩可能也能合一起~~,然后先讨论下哪些修改能接受吧

Reply to this message to post a comment on GitHub.


💬 New comment on BBS#44 墙的倒掉,已经进入按天的倒计时?
by @RPRX

内容没看不过光这标题就已经很搞笑了,我早说过只要国内那些种类繁多的内容审查的法律法规存在着,墙就不会被撤掉,不然前者原地变成空气,举个例子比如你封杀了户子,然而人家直接跑境外平台开号,然后这境外平台又能无梯直连,这跟没封杀有啥区别?点到为止不要键政

因为说白了各种内容审查乃至各种墙的实质主要是两大阵营在争权,~~在各自的地盘里放对方的黑料、洗脑自己的民众什么的,同时通过各种手段封杀对自己不利的黑料、打压对对方有利的言论~~,没有绝对的对错毕竟你上你也干,那些二极管只能证明他智商过低或有利可图,别那么傻

不过必然的尴尬就是两大阵营实控的舆论地盘肯定是一大一小,所以为了势均力敌,~~小的那方必然显得得更极权、手段更直接一些比如动不动就 404、给你上个臭名昭著的 GFW,不然小的那方早就被吞并了,而大的那方手段可以隐蔽些比如收买媒体、顺势占一些价值观制高点什么的~~

说这些既没有站谁也没有给 GFW 找补,毕竟我生理性反感那些封杀下架什么的,只是从两个底层角度来解读 GFW 的存在,换别的星球若有稳定的两大阵营也没差,不然一定早就大吞小,~~另外我越来越发现我也生理性反感某些傻逼,感觉智商没发育及格,这也并非骂人而是字面意思~~

Reply to this message to post a comment on GitHub.

6.2k 0 26 19 67

💬 New comment on BBS#46 CDN代理WebSocket时开启Early Data的风险
by @RPRX

虽然文章经 AI 润色了但风险确实存在,其实开 VLESS Encryption 就行了不用停用 ed,前者是因为不信任 CDN,后者是不想让 CDN 知道你在跑代理?~~然而 CDN 若想查的话都能查出来,停不停用 ed 没差~~,或者换 HTTPUpgrade,它的 ed 机制不是写 header 里、不会进专属 log,但那些 worker & page 不方便开 enc 或换 hu,但可以 XHTTP,再说 WS/HU 有 ALPN 问题本就不被推荐,**现在过 CDN 只推荐 XHTTP + VLESS enc**

总之就是 XHTTP 天生没有 ALPN、延迟等问题,另外过 CDN 最好开个 VLESS enc,~~虽然其实很多人在用 WARP,感觉都挺信任 Cloudflare 的~~

Reply to this message to post a comment on GitHub.

7k 0 18 2 31
Показано 20 последних публикаций.