Comment on page
Surge iOS FAQs
Surge iOS battery consumption consists of two parts: network communication (baseband) battery consumption and CPU battery consumption.
When Surge iOS is turned on, all network requests from applications are taken over and forwarded by Surge, causing all battery consumption generated by network communication to be calculated on Surge when iOS is counting. As a result, Surge's battery usage percentage will be high. However, there is no additional battery consumption in reality.
- If an encrypted proxy is configured for traffic forwarding, additional CPU battery consumption will be generated due to the need for encryption and decryption calculations during forwarding. Generally speaking, this additional overhead is very low and can be basically ignored, but it may cause significant consumption in long-duration, high-bandwidth scenarios, such as iCloud synchronization, App Store application package downloads, etc. However, by default, these operations are usually performed when connected to power.
- If a cron type script is configured and triggered frequently, it may cause additional battery consumption due to constantly waking up the CPU.
In summary, keeping Surge iOS on has a minimal impact on battery consumption. According to our tests, under normal use, the additional consumption is less than 5% in 24 hours, so there is no need to worry.
If your profile comes from someone else, it will automatically update with remote changes (i.e., Managed Profile).
Since remote updates can overwrite local settings at any time, you are not allowed to adjust settings locally in this case to avoid conflicts.
If you want to adjust the profile based on the original hosted profile, you can:
- 1.Create a copy of the managed profile, which will unlink the new profile from the original's automatic updates, allowing you to edit freely.
- 2.Create a Linked Profile based on that profile, referencing only certain sections (usually [Proxy] and [Proxy Group]) from the original, allowing you to edit other sections' related settings. More information: Detached Profile
Simply put, this notification appears when there is indeed a problem with the network, and the network is almost unusable.
Technically, when Surge detects that the handshake time of TCP exceeds 2000 ms, it sends a DNS request to all traditional DNS servers in the current configuration. If no response is received within 2000 ms, it determines the network quality is poor and provides a notification.
- If this notification frequently appears when the network is actually fine, please check if the DNS server configuration is reasonable.
- If you do not wish to receive this notification, you can turn it off individually in the notification settings within Surge.
By default, Surge automatically decides whether to allow forwarding of QUIC/HTTP3 traffic based on the type of proxy, as most proxies are not suitable for forwarding QUIC traffic, causing serious performance issues.
Almost all applications have a mechanism to automatically fallback to HTTPS when QUIC is unavailable, so there is no need to worry about QUIC-BLOCK causing a website to be inaccessible or an app unusable.
Compared to HTTP/2, the QUIC (HTTP/3) protocol only has a slight performance improvement, and since both use TLS/1.3 as the security layer, their security is almost identical. The performance issues caused by inappropriate proxy forwarding far outweigh the improvements of HTTP/3, so there is no need to allow QUIC traffic just for the sake of using HTTP/3.
If you need to use QUIC for development and debugging purposes, adjust the QUIC Block option in the settings of the corresponding proxy policy.
Why are most proxy protocols not suitable for forwarding QUIC traffic? Both TCP and QUIC protocols are reliable transport protocols, meaning they will automatically retransmit a data packet if they detect that it is lost.
Let's look at a hypothetical situation where a TCP-based proxy forwards QUIC and see what problems arise:
- 1.Send data segment A, which is encapsulated in QUIC's UDP packet B, and then encapsulated in TCP packet C through a TCP-based proxy.
- 2.Network jitter occurs, and the C packet is lost.
- 3.TCP protocol detects the loss and retransmits packet C'2.
- 4.QUIC protocol also detects the loss and retransmits packet B'2, which appears as a new data stream in the TCP layer, generating a new TCP packet D.
As you can see, a single packet loss leads to double retransmissions in the nested reliable transport protocols. This is a simple example; severe packet loss would lead to a large number of retransmissions at the QUIC layer. The TCP layer then ensures all QUIC layer retransmissions are delivered (even though they contain the same data), causing congestion to exponentially rise.
This only touches on one of many issues, including double ACK packets and ineffective congestion algorithms.
Therefore, it is advisable to avoid using QUIC on TCP-based proxies. However, if the TCP proxy itself has a good line with few packet losses, and the QUIC traffic is not significant, you might not feel a significant problem in practice. But it still generates unnecessary additional overhead, and performance is far inferior to direct use of TCP layer proxy. Therefore, unless it is for QUIC testing or other developer purposes, please do not adjust the block-quic parameter to allow QUIC traffic.