过年在家折腾sing-box，我可以抛弃surge了
- 内容介绍
- 文章标签
- 相关推荐
这几天春节用了几天sing-box后，丝滑程序不低于surge多少，自由灵活的程度但是要高出很多，作为surge ios/macos几年的用户，其实还是挺顺畅的
| 代理 | 优点 | 缺点 |
|---|---|---|
| sing-box | 灵活自由，支持几乎市场上所有主流协议，支持openwrt、linux、mac、ios等全平台，也能连接其他的vpn虚拟网络接口 | 动手成本高，但是有 GUI.for.SingBox |
| surge | 开箱即用，并有丰富的模块进行去广告等插件，更方便 | 只能在apple上面用 |
总之来说，sing-box全平台的特性很吸引我，至于surge ponte，ipv6用wireguard，代理穿透用frp，反正不管怎么用都是可以替代的，去广告的话，我个人感觉surge也不是很多，都是一些简单的dns去广告，不知道有没有复杂的。
现在来看我更倾向于用sing-box的，surge ios/macos我都想出手了，主要是这么强，还免费！！！！
网友解答：--【壹】--：
我想一劳永逸
--【贰】--：
看来surge的作者人品堪忧啊
--【叁】--：
我看隔壁论坛surge作者好像把vless+reality+vision的特征给提交给相关部门来着
--【肆】--：
那傻狗偷别人文章胡写一气，目的就是喷reality作者，作者早在23年就修复过他说的问题，只不过后来其他作者同步上游被改回来了，无伤大雅的事，更多是私人仇怨
关于我对 REALITY、uTLS、鹦鹉已死，以及 Sukka 那些人的一些看法
已打开 12:37PM - 16 Feb 26 UTC RPRX~~https://blog.skk.moe/post/to-kill-a-parrot-detecting-xtls-vless-reality-server…/ web archive 没存到，这原文就别改了吧~~ 通篇看下来，你就会发现上述文章的核心重点并非技术，而在于“攻击 RPRX”，至于为什么这么恨我，前因是我点出了某些“高端”SS 机场的“共用密码、可被解密”问题，并被一众 SS 中转拥护者、Surge 拥护者嗤之以鼻（参考 [Project X Channel](https://t.me/projectXtls) 几个月前的消息）， 还是那句话：**一旦 Xray 出了什么可被识别（甚至可被轻易解决）的问题那就是天大的问题，然而即使 SS 没有前向安全、共用密码能直接全部解密那也“没有问题”，双标得未免也太离谱了** **最值得载入史册的地方在于他这文章的整个基础，即“RPRX 没有修改 REALITY 库的 maxUselessRecords”本身就是错的**，不是哥们你既然都看到了我早就研究过相关问题、给 uTLS 库和 Golang 官方 TLS 库提交了修改，[那有没有一种可能我早就把 REALITY 库也改了呢？](https://github.com/XTLS/REALITY/commit/dc9a7cef8e8007bce8f73fc2957e57a8b70a4f82)当时还写了一个 [TODO](https://github.com/XTLS/REALITY/blob/cd53f7d5023741301aabb5a7274ed0dd024fbd2c/tls.go#L375) 讲了接下来要做什么，这东西是被其他维护者同步 Golang 上游代码时给 [误改](https://github.com/XTLS/REALITY/commit/0eb1df22cf7e6fecaadc27d58075aaf7a4b9572d) 了，**Sukka 看到代码里是 16 就直接高潮，甚至据此写了七千字来反复论证“RPRX 不懂、不行”，真的是贻笑大方，建议大家了解了这一事实后再回头看下那篇文章，春晚的小品这不就有了吗**，甚至这个问题都不是 Cloak、ShadowTLS v3 那些需要协议层面 breaking change 才能解决的问题，那种才是值得换协议的大新闻，**而现在的情况是未造成大规模封锁且 Xray 推个新版就能一夜修复，当这个问题被公开后就已经对 GFW 没用了**，~~就这都能写个七千字、试图搞个大新闻并造成大规模恐慌也真是对我恨之入骨了~~ 说下我对 REALITY、uTLS、鹦鹉已死的看法吧，**首先鹦鹉当然无法完美模仿，但很遗憾鹦鹉却是反审查中很难避开的一环**，REALITY 的“特征”其实还有很多，比如说 server handshake 消息 TCP 分包发送/粘包发送，data record 的 max size 与切换策略（XTLS 也有这个问题，不过 REALITY 的大规模普及在一定程度上扰乱了公网流量特征）、广泛存在的 timeouts 等，即使全解决了也顶多做到特征符合“端口转发”，**以前没说那么多是因为不想给 GFW 提供弹药，等它自己研究出来我再改，这样可以延长拉锯时间、不至于快进到 IP 白名单**，如果是 QUIC 那就更多了，所以 REALITY 至今没出 QUIC 版，至于 uTLS，但凡用 uTLS 库的都知道它只模拟指纹而完全不模拟动态特征，毕竟根本模拟不完，~~除非你拿 AI 把 BoringSSL 翻译成 Golang~~，然而现在的问题就是 GFW 已经针对 Golang TLS 指纹，而 Golang 上没有更好的 uTLS 原生替代品，就像某些地区/审查系统存在 SNI 白名单，[所以 REALITY 成了一个不得不长期存在、维护的协议](https://t.me/projectXtls/1428)，**这么多年了有些人嘴里一口一个鹦鹉已死，丝毫没有想过完全不要鹦鹉的话遇到 SNI 白名单难道直接缴械投降吗？这么说吧是可以完全不要鹦鹉，你行你上** **最后说下我对 Sukka 那些人的看法，他们已经不是非蠢即坏，而是既蠢又坏**，“蠢”不光体现在上面闹出的笑话，也体现在研究协议没几天、发现了协议开发者人尽皆知的“针对特征比处理特征简单”就洋洋自得，我还记得此前他们得出这一结论后兴高采烈，**那有没有一种可能这是众所周知的、但凡是个研究协议的人一开始都能得出这个结论呢？你们高调宣布这一结论恰恰说明了你们才刚入门而已，并且截止目前你们发现的那些“特征”虽说也有一定价值但都不涉及 breaking change，没有一个比得上我发现的 SS AEAD 移花接木问题、Trojan TLS-in-TLS PoC、Cloak x25519 问题，这些都是必须要改协议的，而不涉及 breaking change 的我都记不清多少了，直接发版修复就行，谁跟你们一样发现个这种小问题就到处投稿、恨不得搞个大新闻？**“坏”体现在他们直接就是为 GFW 工作，[先给华为、派网、新华三、深信服提交了问题](https://github.com/XTLS/Xray-core/issues/5696)，几个月后专门选除夕这一天公开来恶心人，**也就是说他们的目标并非保障人们的通讯自由，而是就是希望 GFW 封掉某些地区不得不依赖的 REALITY 协议，平时小打小闹就算了但这已经突破做人的底线了，我指出 SS 机场的共用密码问题是因为 GFW 确实能直接解密流量、不应当使用、只能换机场来解决，而他们却是看到 REALITY 有个小的、能被轻易修复的识别（而非解密）问题后希望 GFW 默默地封掉 REALITY，用一个并非紧要的问题换来对正在被人们广泛使用的直连协议的直接封锁而非帮助人们翻出去，再回想 Sukka 此前的“暴论”，到底谁是 GFW 的人呢？当初某些人那么维护共用密码的 SS 到底是何居心呢？** 一场闹剧，帮助大家看清一群人。
--【伍】--：
毋需担心，再说你换又能换谁呢
--【陆】--：
singbox的耗电量怎么样？小火箭我感觉好像耗电多一点，其他我都满意
--【柒】--：
毛坯房和精装修的区别
--【捌】--：
没测过，但是我肯定用起来肯定比小火箭难用，因为sing-box并不是开箱即用
--【玖】--：
用GitHub - GUI-for-Cores/GUI.for.SingBox: Modern, lightweight desktop app built with Wails (Go) and Vue 3. Efficient, cross-platform, and fast. 是不是就没这个问题，都不需要自己配置了，只需要自己加协议
--【拾】--：
我感觉还好，一般半年左右才更新一次配置
--【拾壹】--：
reality就挺好的，没必要换
--【拾贰】--：
多少是有点宗教软件，其作者以及部分用户非常之高傲，其软件既不开源，snell也不许逆向，而sukka又写文章说自己给某某提交漏洞，其心可诛，其心可诛
--【拾叁】--：
佬，现在协议比较推荐哪一个呢，新出的anytls怎样
--【拾肆】--：
可以的。sing-box 很好用，建议博主用 ai agent 帮你配置好。你直接用 ai 给你配置、测试好的。
--【拾伍】--：
那佬，那就根本不用担心这个问题了吗？我还说打算换个协议呢
--【拾陆】--：
surge经常被骂，关键是还有一堆人用
--【拾柒】--：
这么强吗，这么说我都想试试了，我目前手机和电脑都是surge
--【拾捌】--：
问题是sing-box更新太快了，手搓的配置还没捂热呢，某些特性就准备在新版废弃了
--【拾玖】--：
快快用 sing-box 罢
这几天春节用了几天sing-box后，丝滑程序不低于surge多少，自由灵活的程度但是要高出很多，作为surge ios/macos几年的用户，其实还是挺顺畅的
| 代理 | 优点 | 缺点 |
|---|---|---|
| sing-box | 灵活自由，支持几乎市场上所有主流协议，支持openwrt、linux、mac、ios等全平台，也能连接其他的vpn虚拟网络接口 | 动手成本高，但是有 GUI.for.SingBox |
| surge | 开箱即用，并有丰富的模块进行去广告等插件，更方便 | 只能在apple上面用 |
总之来说，sing-box全平台的特性很吸引我，至于surge ponte，ipv6用wireguard，代理穿透用frp，反正不管怎么用都是可以替代的，去广告的话，我个人感觉surge也不是很多，都是一些简单的dns去广告，不知道有没有复杂的。
现在来看我更倾向于用sing-box的，surge ios/macos我都想出手了，主要是这么强，还免费！！！！
网友解答：--【壹】--：
我想一劳永逸
--【贰】--：
看来surge的作者人品堪忧啊
--【叁】--：
我看隔壁论坛surge作者好像把vless+reality+vision的特征给提交给相关部门来着
--【肆】--：
那傻狗偷别人文章胡写一气，目的就是喷reality作者，作者早在23年就修复过他说的问题，只不过后来其他作者同步上游被改回来了，无伤大雅的事，更多是私人仇怨
关于我对 REALITY、uTLS、鹦鹉已死，以及 Sukka 那些人的一些看法
已打开 12:37PM - 16 Feb 26 UTC RPRX~~https://blog.skk.moe/post/to-kill-a-parrot-detecting-xtls-vless-reality-server…/ web archive 没存到，这原文就别改了吧~~ 通篇看下来，你就会发现上述文章的核心重点并非技术，而在于“攻击 RPRX”，至于为什么这么恨我，前因是我点出了某些“高端”SS 机场的“共用密码、可被解密”问题，并被一众 SS 中转拥护者、Surge 拥护者嗤之以鼻（参考 [Project X Channel](https://t.me/projectXtls) 几个月前的消息）， 还是那句话：**一旦 Xray 出了什么可被识别（甚至可被轻易解决）的问题那就是天大的问题，然而即使 SS 没有前向安全、共用密码能直接全部解密那也“没有问题”，双标得未免也太离谱了** **最值得载入史册的地方在于他这文章的整个基础，即“RPRX 没有修改 REALITY 库的 maxUselessRecords”本身就是错的**，不是哥们你既然都看到了我早就研究过相关问题、给 uTLS 库和 Golang 官方 TLS 库提交了修改，[那有没有一种可能我早就把 REALITY 库也改了呢？](https://github.com/XTLS/REALITY/commit/dc9a7cef8e8007bce8f73fc2957e57a8b70a4f82)当时还写了一个 [TODO](https://github.com/XTLS/REALITY/blob/cd53f7d5023741301aabb5a7274ed0dd024fbd2c/tls.go#L375) 讲了接下来要做什么，这东西是被其他维护者同步 Golang 上游代码时给 [误改](https://github.com/XTLS/REALITY/commit/0eb1df22cf7e6fecaadc27d58075aaf7a4b9572d) 了，**Sukka 看到代码里是 16 就直接高潮，甚至据此写了七千字来反复论证“RPRX 不懂、不行”，真的是贻笑大方，建议大家了解了这一事实后再回头看下那篇文章，春晚的小品这不就有了吗**，甚至这个问题都不是 Cloak、ShadowTLS v3 那些需要协议层面 breaking change 才能解决的问题，那种才是值得换协议的大新闻，**而现在的情况是未造成大规模封锁且 Xray 推个新版就能一夜修复，当这个问题被公开后就已经对 GFW 没用了**，~~就这都能写个七千字、试图搞个大新闻并造成大规模恐慌也真是对我恨之入骨了~~ 说下我对 REALITY、uTLS、鹦鹉已死的看法吧，**首先鹦鹉当然无法完美模仿，但很遗憾鹦鹉却是反审查中很难避开的一环**，REALITY 的“特征”其实还有很多，比如说 server handshake 消息 TCP 分包发送/粘包发送，data record 的 max size 与切换策略（XTLS 也有这个问题，不过 REALITY 的大规模普及在一定程度上扰乱了公网流量特征）、广泛存在的 timeouts 等，即使全解决了也顶多做到特征符合“端口转发”，**以前没说那么多是因为不想给 GFW 提供弹药，等它自己研究出来我再改，这样可以延长拉锯时间、不至于快进到 IP 白名单**，如果是 QUIC 那就更多了，所以 REALITY 至今没出 QUIC 版，至于 uTLS，但凡用 uTLS 库的都知道它只模拟指纹而完全不模拟动态特征，毕竟根本模拟不完，~~除非你拿 AI 把 BoringSSL 翻译成 Golang~~，然而现在的问题就是 GFW 已经针对 Golang TLS 指纹，而 Golang 上没有更好的 uTLS 原生替代品，就像某些地区/审查系统存在 SNI 白名单，[所以 REALITY 成了一个不得不长期存在、维护的协议](https://t.me/projectXtls/1428)，**这么多年了有些人嘴里一口一个鹦鹉已死，丝毫没有想过完全不要鹦鹉的话遇到 SNI 白名单难道直接缴械投降吗？这么说吧是可以完全不要鹦鹉，你行你上** **最后说下我对 Sukka 那些人的看法，他们已经不是非蠢即坏，而是既蠢又坏**，“蠢”不光体现在上面闹出的笑话，也体现在研究协议没几天、发现了协议开发者人尽皆知的“针对特征比处理特征简单”就洋洋自得，我还记得此前他们得出这一结论后兴高采烈，**那有没有一种可能这是众所周知的、但凡是个研究协议的人一开始都能得出这个结论呢？你们高调宣布这一结论恰恰说明了你们才刚入门而已，并且截止目前你们发现的那些“特征”虽说也有一定价值但都不涉及 breaking change，没有一个比得上我发现的 SS AEAD 移花接木问题、Trojan TLS-in-TLS PoC、Cloak x25519 问题，这些都是必须要改协议的，而不涉及 breaking change 的我都记不清多少了，直接发版修复就行，谁跟你们一样发现个这种小问题就到处投稿、恨不得搞个大新闻？**“坏”体现在他们直接就是为 GFW 工作，[先给华为、派网、新华三、深信服提交了问题](https://github.com/XTLS/Xray-core/issues/5696)，几个月后专门选除夕这一天公开来恶心人，**也就是说他们的目标并非保障人们的通讯自由，而是就是希望 GFW 封掉某些地区不得不依赖的 REALITY 协议，平时小打小闹就算了但这已经突破做人的底线了，我指出 SS 机场的共用密码问题是因为 GFW 确实能直接解密流量、不应当使用、只能换机场来解决，而他们却是看到 REALITY 有个小的、能被轻易修复的识别（而非解密）问题后希望 GFW 默默地封掉 REALITY，用一个并非紧要的问题换来对正在被人们广泛使用的直连协议的直接封锁而非帮助人们翻出去，再回想 Sukka 此前的“暴论”，到底谁是 GFW 的人呢？当初某些人那么维护共用密码的 SS 到底是何居心呢？** 一场闹剧，帮助大家看清一群人。
--【伍】--：
毋需担心，再说你换又能换谁呢
--【陆】--：
singbox的耗电量怎么样？小火箭我感觉好像耗电多一点，其他我都满意
--【柒】--：
毛坯房和精装修的区别
--【捌】--：
没测过，但是我肯定用起来肯定比小火箭难用，因为sing-box并不是开箱即用
--【玖】--：
用GitHub - GUI-for-Cores/GUI.for.SingBox: Modern, lightweight desktop app built with Wails (Go) and Vue 3. Efficient, cross-platform, and fast. 是不是就没这个问题，都不需要自己配置了，只需要自己加协议
--【拾】--：
我感觉还好，一般半年左右才更新一次配置
--【拾壹】--：
reality就挺好的，没必要换
--【拾贰】--：
多少是有点宗教软件，其作者以及部分用户非常之高傲，其软件既不开源，snell也不许逆向，而sukka又写文章说自己给某某提交漏洞，其心可诛，其心可诛
--【拾叁】--：
佬，现在协议比较推荐哪一个呢，新出的anytls怎样
--【拾肆】--：
可以的。sing-box 很好用，建议博主用 ai agent 帮你配置好。你直接用 ai 给你配置、测试好的。
--【拾伍】--：
那佬，那就根本不用担心这个问题了吗？我还说打算换个协议呢
--【拾陆】--：
surge经常被骂，关键是还有一堆人用
--【拾柒】--：
这么强吗，这么说我都想试试了，我目前手机和电脑都是surge
--【拾捌】--：
问题是sing-box更新太快了，手搓的配置还没捂热呢，某些特性就准备在新版废弃了
--【拾玖】--：
快快用 sing-box 罢