Surge TestFlight Feed

macOS 27 Beta 4 Local Network Issue A small number of users running macOS 27 Beta 4 have reported that Surge may fail to access services on the local network, returning a “No route to host” error. After investigation, we have confirmed that this is caused by an issue with the system’s Local Network permission database. If the problem persists, you can try resetting the Local Network permission database by running: tccutil reset LocalNetwork or wait for a future macOS beta update, as the issue appears to be a system bug.

Surge Ponte Service Notice Over the past three days, a small number of users have reported that Surge Ponte is unable to access iCloud, resulting in synchronization failures. After investigation, we have confirmed that this is caused by a server-side issue with Apple’s CloudKit service rather than Surge itself. The issue has been reported to Apple and can only be resolved by Apple. If you are affected, please allow Apple a few days to resolve the issue. Most affected users are using iCloud China (operated by GCBD), although we have also received a small number of reports from users on the international iCloud service. To reduce our dependency on a single cloud provider, we have also started designing a general Bring Your Own Storage (BYOS) mechanism. Once available, users will be able to use their preferred cloud storage service for both configuration synchronization and Surge Ponte data synchronization. We will share more details as development progresses.

More Details About the Tailscale Update * The new version will automatically add the user’s MagicDNS domain as a highest-priority DOMAIN-SUFFIX rule, such as DOMAIN-SUFFIX,tail123456.ts.net. Therefore, when using MagicDNS for access, there is no need to manually configure the rule. * Surge’s default policy for Tailscale is to start on demand. If there are no active requests for 600 seconds, it will automatically disconnect to avoid unnecessary resource consumption. If you want to stay continuously online like the official client and avoid additional waiting during initialization, you can configure idle-keepalive = -1.

New Feature: Surge as MTProto Server Surge now can operate as an incoming MTProto proxy server for Telegram. Please read manual for more information: https://manual.nssurge.com/ TL;DR Using MTProto instead of SOCKS or VIF to take over Telegram can: 1. Telegram has a notorious SOCKS5 bug in which it can put an IPv6 destination address into an IPv4 request. The malformed destination causes a large number of invalid connection attempts to be sent to Surge. MTProto avoids this path entirely. 2. Force connections to Telegram servers over IPv6. Telegram’s IPv4 servers have a bug that can easily cause the connection to hang without responding. IPv6 nodes do not have this issue, and MTProto allows the intermediary proxy to determine the specific DC service address. Therefore, setting ipv6=true can resolve this persistent problem. (The proxy server must support IPv6 forwarding.)

Snell v6.0.0 RC1 Fix the issue where the first few UDP packets may be truncated when forwarding starts. https://kb.nssurge.com/surge-knowledge-base/release-notes/snell

Tailscale Engine Rewrite In previous beta versions, Surge’s Tailscale implementation was based on the official experimental tailscale-rs library. Because its feature set and performance did not fully meet Surge’s requirements, this release replaces that integration with a new proprietary implementation built directly into Surge’s networking engine. The new implementation provides broader functionality, significantly better performance, and richer runtime diagnostics. 1. Direct peer-to-peer connectivity, including NAT traversal and path discovery, is now supported. Surge automatically prefers a direct connection when available and falls back to DERP when necessary. The new derp-only option can be used to force all peer traffic through DERP. 2. Single-threaded data-plane throughput has been significantly improved, reaching up to approximately 1.5 Gbps in our lab tests—comparable to the official Tailscale client under the same test conditions. 3. Exit node support has been added. A Tailscale policy can now route Surge-selected traffic through a configured exit node and can therefore be used as a regular outbound policy. This affects only traffic assigned to that policy by Surge and does not change the device-wide default route. 4. Routes advertised by authorized Tailscale subnet routers are now supported. MagicDNS is now better supported. 5. Surge now uses Tailscale-aware latency testing. When exit node isn't configured, Surge performs a native Tailscale connectivity probe against an online peer. If no suitable peer is available, the home DERP server is tested instead. When exit node or test-url is configured, the standard HTTP test process is used. Additional initialization time is allowed for control-plane setup and the initial WireGuard handshake. 6. Extensive Tailscale runtime diagnostics have been added to the UI, including control connection state, assigned addresses, exit node status, DERP regions, direct-versus-relay peer paths, peer latency, active connections, endpoints, and MagicDNS information. 7. Existing Tailscale profiles and persisted node identities remain compatible; no profile migration is required. We plan to add inbound access over WireGuard and Tailscale in a future version, allowing remote devices to connect to Surge and use it as a network gateway. Notice: Due to the core engine replacement, Tailscale needs to be registered again. If you did not previously enable the reuse option for the auth key, you must generate a new auth key to complete the new device registration process. Please check the manual for more information: https://manual.nssurge.com/policy/tailscale.html

Abort Assert Log Surge includes a number of assert checks in its code. Assert checks are a common development and debugging mechanism used to detect situations where the program reaches a state that is different from what the developers expected. Seeing an assert message does not necessarily mean that Surge has crashed or other issues. In many cases, the app can continue working normally, and the assert simply serves as a signal for the developers to review that part of the code. When an assert is triggered, Surge may automatically save certain temporary logs that were previously held in memory into a log file. This is done to help developers understand what happened before the assert was triggered. This behavior is expected and should not be interpreted as abnormal memory usage or a memory leak. Assert triggers may be seen more often in beta versions, because beta builds are designed to help identify and diagnose potential issues before a stable release. If Surge continues to work normally, the message can usually be ignored. If you notice repeated crashes, broken functionality, or other reproducible problems together with this message, please report the issue with the relevant logs so we can investigate further

Licensing System Update You can now deactivate an inactive device directly from the license management page on the Surge website for both Surge Mac and Surge iOS, without performing a full license reset. * A device is considered inactive if it has not connected to the internet for more than 72 hours. * Each license may perform this inactive-device deactivation operation once every 7 days. * Regular device deactivation is not affected by this limitation.

Snell 6.0 beta 2 Snell v6 beta 3 has added a mode setting. 1. mode=default Default mode, enables traffic obfuscation and AES encryption. 2. mode=unshaped Disables obfuscation and uses only AES encryption. Compared with the default mode, throughput performance can be improved by about 10%. This mode is equivalent to Snell v3, where the encrypted traffic appears completely random. 3. unsafe-raw Disables encryption and obfuscation, forwarding all traffic in plaintext. It should only be used in secure network environments, such as an intranet or under another secure tunnel. Please note that the server mode and client mode must be consistent.

Snell 6.0 beta 2 * Fixed an issue where performance unexpectedly dropped significantly * Fixed an issue with external dynamic dependency libraries Please note that this version adjusts the protocol profile, so Surge Mac also needs to be updated to the latest version.

Snell v6 Beta Introduced Snell v6, featuring PSK-derived deployment-level protocol diversity that generates unique traffic characteristics for each deployment, reducing reliance on a single protocol fingerprint while preserving Snell’s core goals of performance, deployment simplicity, accurate error reporting, and full TCP semantics. Snell v6 also adds new IPv4/IPv6 network stack controls including dns-ip-preference and multi-address listen support, and is currently available for beta testing. Please check our blog for more information: https://nssurge.com/blog/snell-v6/

Surge Mac Beta 6.7.0 now supports Tailscale as a proxy policy. With this feature, Surge can join your Tailscale tailnet directly and route selected traffic through Tailscale peers using the existing Surge rule system. You can use Tailscale IPs, and tailnet-only services together with Surge policies, policy groups, DNS handling, traffic logging, and rule-based routing. Please check Surge Knowledge Base for more information: https://kb.nssurge.com/surge-knowledge-base/guidelines/tailscale

A Brief Update on Surge The Surge team has recently gone through several internal changes, and we would like to share a few updates with our users. Support Operations We have expanded our support operations by adding dedicated customer support staff and technical specialists. This allows us to respond to inquiries more efficiently while keeping our engineering team focused on product development. Communication Channels We are currently reorganizing our external communication channels. As part of this effort, we have launched a new official blog to share technical details about Surge and insights from our development process. SOC 2 Alignment We have begun aligning our internal processes with SOC 2 requirements. This work reflects our continued investment in improving operational maturity, security practices, and overall reliability. It is especially relevant for enterprise customers with strict security and compliance expectations. Product Development We know many users are most interested in what’s next for Surge. Since the official release of Surge Mac v6 on July 1, 2025, we have shipped 428 beta builds, 14 stable releases, and nearly one hundred improvements and optimizations in less than a year. The full release history is available in our release notes: https://nssurge.com/support/mac/release-notes. At the same time, we are actively working on Tailscale integration. While we are not ready to provide a formal ETA, we expect an early beta to be available soon. As always, our focus remains on shipping features only when they meet the standards of quality and system-level integration that users expect from Surge. Thank you for your continued support and patience. More updates will be shared as work progresses. https://nssurge.com/blog/a-brief-update-on-surge/

Surge Mac Tips 由于现在很多应用程序包内存在多个二进制文件，因此传统 PROCESS-NAME 规则配置需要多条才能完全匹配。 自 Surge Mac 6.0 版本开始，PROCESS-NAME 规则的用法就已经扩展，当以 / 结尾时将进行前缀匹配，如 PROCESS-NAME,/Applications/ChatGPT.app/ 可匹配 ChatGPT.app 应用包内所有二进制。 详见：https://manual.nssurge.com/rule/process.html

Surge iOS & Mac Beta 版本更新日志 • Surge Mac 版本现在可以通过 UI 编辑策略组图标，同时除了 URL 图标，也可以使用 Emoji、Surge 内置图标库和 SF Symbols。 • 策略组图标现在直接写入配置。 • iOS 版本的图标配置存储逻辑调整，现在在配置文件可编辑的情况下，将优先写入配置，以保证和 Mac 版本互通。仅当配置为只读配置时，使用独立的 UI 配置文件存储。

Surge iOS & Mac Beta 版本更新日志 - HTTP/2 CONNECT 和 TrustTunnel 代理现在支持 multiplex，由于过多子链接复用同一个 TCP 连接，可能产生性能问题，因此默认只允许最多 3 个子连接，可通过配置策略参数 max-streams 调整。

关于部分历史协议维护状态的调整 以下历史协议后续将进入维护冻结状态： * AEAD 版本之前的旧版 Shadowsocks * TUIC v4 * VMess 相关协议的核心代码和兼容能力仍会保留，现有配置不会受到影响；但后续版本中，对应的 UI 配置入口将逐步移除。

Surge iOS & Mac Beta 版本更新日志 - 新增 HTTP/2 CONNECT 代理支持，可通过 h2-connect 类型配置基于 HTTP/2 的 CONNECT 代理连接。 - HTTP, HTTPS, HTTP/2 CONNECT, TrustTunnel 代理现支持自定义请求头，可在代理配置中使用 headers= 添加额外 header，例如：

Proxy = http, example.com, 8080, headers=X-Client:Surge;X-Token:abc
Proxy = h2-connect, example.com, 443, headers=X-Padding:<random-string(16-32)>

自定义 header 支持 <random-string(n)> 与 <random-string(min-max)> 占位符，连接时会自动生成 URL-safe 随机字符串，适用于需要动态 padding 或请求特征扰动的场景。

关于 Surge iOS 功能更新订阅机制的调整 自 Surge iOS 推出功能更新订阅机制以来，我们一直希望在「持续演进产品能力」与「保障长期使用体验」之间保持合理的平衡。经过评估，我们决定进行如下调整： 1. 未来新增的所有代理协议兼容支持，将不再纳入功能更新订阅范围，所有用户均可直接使用。 2. 现已实验性支持的 TrustTunnel，也不会存在订阅限制，可以直接使用。 我们认为，协议兼容性应当作为长期稳定提供的基础能力，而不是阶段性的增量功能。这意味着，未来用户无需因为订阅状态，而担心基础协议支持的可用性；新的协议兼容能力也能够更直接、更持续地向所有用户开放。 调整后，订阅更新将更聚焦于新的高级功能，而协议兼容性本身，则会作为产品的长期基础能力持续维护。 与此同时，代理协议生态本身也始终处于持续变化之中。一些协议会不断演进，也有一些协议会逐渐退出主流使用场景。为了保证 Surge 长期稳定的代码库维护与整体产品质量，我们也会结合实际使用情况，对部分历史协议进入维护冻结状态，或在未来逐步结束支持。 我们会尽可能谨慎地处理相关调整，并提前进行说明，以减少对现有用户配置与使用体验的影响。 感谢大家一直以来的支持与反馈。

关于 Surge 用户交流群的说明 近期，我们多次收到与部分 Surge 用户交流群相关的邮件，包括请求协助处理群内争议、解除封禁等事项。对此，我们希望再次说明： * 各平台上的 Surge 用户交流群均由用户自发创建和维护，Surge 团队从未参与其管理，也不具备任何控制权。 * 部分交流群中的热心用户会整理社区反馈，并转达给我们参考。这是我们了解用户意见和建议的渠道之一。但除此之外，Surge 团队与相关交流群不存在其他合作或管理关系，群内用户及管理员的言论也不代表 Surge 团队立场。 * Surge 官方讨论社区为：https://community.nssurge.com/ 。该社区仅用于技术相关的讨论与交流。该 Telegram 频道则为唯一官方公告渠道。 感谢各位的理解。