cookie

نحن نستخدم ملفات تعريف الارتباط لتحسين تجربة التصفح الخاصة بك. بالنقر على "قبول الكل"، أنت توافق على استخدام ملفات تعريف الارتباط.

avatar

Surge TestFlight Feed

该频道用于提供关于 Surge iOS/Mac/tvOS 的最新 beta 版本信息

إظهار المزيد
مشاركات الإعلانات
5 139
المشتركون
+1124 ساعات
+1077 أيام
+31130 أيام

جاري تحميل البيانات...

معدل نمو المشترك

جاري تحميل البيانات...

Surge iOS Beta 更新日志 - 支持在始终开启开关打开的情况下,通过小组件/控制中心/捷径关闭 Surge - 支持在 Surge VPN Profile 未被选中的情况下(其他 VPN 运行时),通过小组件/控制中心/捷径开启 Surge
إظهار الكل...
38🎉 5👍 2🔥 1🥰 1🤯 1
Surge iOS Beta 更新日志 - 支持在 iOS 18 beta 下在控制中心里直接开关 Surge
إظهار الكل...
👍 87 8🤔 5🤩 5
Surge Mac Beta 更新日志 所有主机名列表参数类型新增关键字 <simple-hostname>,用于匹配不带 . 的主机名,如
always-real-ip = -<simple-hostname>
(上述配置可以用来在增强模式中使用 NetBIOS 主机名连接 SMB 服务器)
إظهار الكل...
👍 5 2
最新版本与 Tailscale 联合使用的配置样例
[Host]
*.ts.net = server:100.100.100.100

[Rule]
IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
إظهار الكل...
10🔥 1
新版本已完成 TCP 的路由自动判定,现在对于这种情况规则只需要使用 DIRECT 即可,会遵循系统路由表。
إظهار الكل...
👍 2 1
配置样例
[Proxy]
Tailscale = DIRECT, interface = utun9

[Host]
*.ts.net = server:100.100.100.100

[Rule]
IP-CIDR,100.64.0.0/10,Tailscale,no-resolve
旧版本中 [Host] 中的 DNS 服务器设置在增强模式下是无法生效的
إظهار الكل...
👍 9🤯 9
Surge Mac Beta 更新日志 在之前的版本中,若开启了增强模式,由于系统的路由表已被 Surge 覆盖,所以所有向外发出的数据包,会被强制使用主 interface 发出,而不经由路由表,以避免产生死循环。 但这也导致在存在多网卡或其他 VPN 的情况下,数据包无法被从正确的 interface 上发出。 该版本改进了相关设计,现在 Surge 在增强模式下会自动检查路由,如果存在更高优先级的小路由,则依然使用标准路由发出 UDP 数据包(主要是 DNS,但请注意单域名查询时只能有一个 53 DNS 服务器方可生效),以增强兼容性。但目前暂不支持 TCP 数据包的自动判断,依然需要通过 DIRECT 策略别名进行手动配置。
إظهار الكل...
14👍 4🥰 2
Surge iOS & Mac Beta 更新日志 - 根据用户反馈和更多测试,允许 QUIC 流量带来的弊端会更大,该版本恢复了 block-quic 参数。(ChatGPT 的 Voice Mode 问题经反复测试确认为因 QUIC 和 HTTP/2 连接的服务器不同可能导致的行为不一致,实际上不管是否允许 QUIC 流量均有可能失败) - 优化了阻拦 QUIC 流量的实现方法,以提高让客户端正确回退的可能性 - Smart 组当不存在子策略时,也会使用 SUBSTITUTE 策略(DIRECT)而非直接失败。 - 修正 TLS 类协议,在 sni=off 的设置下,server-cert-fingerprint-sha256 参数未能生效的问题 - [iOS] 优化了请求详情页的 IP 地址展示 - [iOS] 编辑策略组时不再可以将自身作为子策略加入
إظهار الكل...
👍 28 4🤔 2👏 1😱 1
关于 QUIC 流量的代理转发 先前我们已经进行过有关的科普,为什么在基于 TCP 的代理上进行 QUIC 流量转发不是一个好主意,因为在网络环境差时会导致 QUIC over TCP 的重发风暴。 除此之外,即使由 over UDP 的代理转发 QUIC,也还会遇到另一个性能问题:流控的链路过长。在转发 TCP 数据流时,Client <-> Proxy 与 Proxy <-> Server 两段链路间有着独立的流控和缓冲区,大部分情况下这是性能的最优解。但是如果使用的是 QUIC 协议,由于流控的相关信息也是加密的,所以只能由 Client <-> Server 间直接完成流控。在网络质量较差时的表现可能远不如前者。 因此我们一直推荐屏蔽 QUIC 流量以逼迫App/浏览器回退到 HTTP/2,这是最合适于代理的工作模式。但是由于副作用就是当遇到无法正常回退的 App 时会导致异常。 针对这样的问题我们暂时无法给出比较通用的推荐配置,我们会继续研究更好的解决方案。
إظهار الكل...
👍 40 3
Surge iOS &Mac Beta 更新日志 - 部分应用在 QUIC 流量被阻止的情况下,无法正确回退到 HTTP/2(如 ChatGPT 的 Voice Mode),预计随着 QUIC 的流行,这种情况可能会越来越多。从该版本起,我们取消了策略的 quic-block 参数,不再对 QUIC 进行自动阻止。交给用户由规则自行决定。 - 优化了 DNS 的请求日志,现在会显示更多的信息,且在规则系统未触发 DNS 时,如果是 DIRECT 策略直连也可以显示 DNS 的相关日志了 - 在删除策略时,如果该策略被策略组所使用,现在允许直接删除并将自动从所有策略组移除 - 建立 Subnet 策略组时,现在可以使用 Subnet 表达式的编辑向导
إظهار الكل...
👍 16 3