Surge FAQs

Surge iOS Specific FAQs

Explanation of Surge iOS Battery Consumption

Surge iOS battery consumption consists of two parts: network communication (baseband) battery consumption and CPU battery consumption.

About network communication (baseband) 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.

About CPU battery consumption

• 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 2% in 24 hours, so there is no need to worry.

Some users may think that Surge is very power-consuming because the percentage occupied by Surge in the system's power consumption statistics is high. Please note that this percentage refers to the proportion of total power consumed during this period attributed to Surge, not the remaining power consumed by Surge. Since Surge NE runs persistently in the background, if you have barely used your device during this period, even if Surge has only consumed a minimal amount of power, it will still be recorded as 100%.

Surge Mac Specific FAQs

Why can only IPs be seen in TCP requests and not domain names

If you find that all TCP requests in the Dashboard are displayed as IP addresses and domain names are not shown, it means that Surge failed to hijack DNS. For a detailed explanation of the principle, please refer to: 《Surge Official Chinese Guide: Understanding Surge Principles》

Possible reasons and solutions include:

• First, please check whether the DNS settings of the device are set to Surge's dedicated DNS address: 198.18.0.2. Surge automatically modifies the DNS of the current device when Enhanced Mode is enabled, and automatically configures this DNS for client devices under DHCP mode.

• Some operating systems or browsers support DoH/DoT or other encrypted DNS protocols, and Surge cannot hijack such DNS requests. Please manually disable this feature.

• Other software that hijacks system DNS is installed on the device.

Requests not displayed in the request viewer

If requests are not displayed in the Surge request viewer, you can troubleshoot in the following order:

1. Confirm that Surge has taken over the network of the local or another device:

• Enabling the Set as System Proxy option can take over most HTTP/HTTPS requests from the current device.

• Enabling Enhanced Mode can take over almost all requests from the current device.

You can confirm whether the takeover was successful through the client and process list on the Surge main interface. If there are items, it means the takeover was successful.

1. Confirm the filter settings of the request viewer

In the Capture page of the Surge main program, you can configure the request viewer capture filter parameters. If these parameters are not configured properly, the request viewer may not display results.

How to deal with abnormal Helper

If the Surge Mac Helper is abnormal, it will cause the system proxy to not be set and Enhanced Mode cannot be turned on. (Force cleaning with CleanMyMac or other cleaning software may cause this problem)

Please follow these steps to fix:

1. Open Surge Mac's settings interface, select System Permissions Overview, and click Remove Helper.

2. Enter your system login password.

3. Click Open Terminal.

4. Enter your system login password again in the terminal window and press Enter.

5. Restart the computer.

6. Open Surge, try to check Set as System Proxy, and enter the system password to reinstall the Helper.

Since macOS is a developmental system, the causes of this problem can be very complex. If it still doesn't work, you may need to try resetting the entire system.

Using Surge Mac and VPN together

If you connect to another VPN while Surge is running, there may be problems. Try turning off Enhanced Mode. If you need to enable Enhanced Mode, you need to use a custom direct policy to force binding interface, as detailed in the manual.

If you encounter problems with domain names in the intranet not being resolved, please:

1. If the VPN is correctly configured with Split DNS, then the system can perform DNS resolution to get the correct result. Use the Local DNS Mapping feature to directly configure the intranet domain name to be resolved by syslib.

[Host]
*.internal.example.com = server:syslib

1. Please note that the server:syslib parameter will not work when Enhanced Mode is enabled. You can use the Local DNS Mapping feature to directly hand over the intranet domain name to the intranet DNS for resolution.

[Host]
*.internal.example.com = server:10.0.0.1

If this domain name can also be accessed from the public network, such a configuration may cause problems. (You can solve this by using a DNS script to determine the environment)

Enhanced Mode compatibility issues

The principle of Surge Mac's Enhanced Mode is to take over all traffic through a virtual network card. This mode of operation may cause compatibility issues, which may manifest as slow internet speed, Surge being closed, or Surge responding slowly, etc. The following are some known programs that may cause conflicts.

• AdGuard

• Viscosity

• Little Snitch

Why do I get a message saying that I can't modify various settings when I try to change them?

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

Surge iOS and Mac Common FAQs

Explanation of the skip-proxy parameter

The skip-proxy parameter in the configuration may be misunderstood by some users due to naming issues. In short, when Surge iOS/Mac configures itself as the system proxy, it also configures the content in the skip-proxy parameter to the system's "Bypass Proxy" settings, just like manually configuring the network proxy.

• If Surge Mac only checks "Set as System Proxy" and does not enable Enhanced Mode, then the requests of the hostnames in the parameter will not be taken over by Surge, and all Surge-related features will not take effect.

• If Surge Mac checks "Set as System Proxy" and enables Enhanced Mode, or if it is on Surge iOS, then the parameter will change the takeover mode of the corresponding requests from proxy takeover to Surge VIF takeover. Surge's various features will still work, but there will be differences in detail.

So, it does not mean that the hostnames configured in the skip-proxy parameter will not use proxy forwarding. This parameter only affects the way requests are taken over by Surge.

• For the specific differences in takeover methods, please refer to Official Guidance：Understanding Surge.

• Some Apps may ignore and skip content in the proxy even if they follow the system proxy settings, depending on the application's proxy implementation.

Why do I get a message saying that I can't modify various settings when I try to change them?

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

Why does Surge frequently notify me of poor network quality?

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.

Why does Surge block QUIC traffic when proxy forwarding?

By default, Surge automatically blocks QUIC traffic sent to the proxy server, because a proxy is not suitable for forwarding QUIC traffic and will cause serious performance issues.

Almost all applications are capable of automatically falling back to HTTPS when QUIC is unavailable, so you don’t need to worry about any website becoming inaccessible or an app being unusable because of QUIC-BLOCK.

Compared with HTTP/2, the QUIC (HTTP/3) protocol only provides a slight performance improvement, and since both use TLS/1.3 as the security layer, their security is almost identical. The performance penalty introduced by proxy forwarding greatly outweighs the marginal improvement 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, please adjust the QUIC Block option in the settings of the corresponding proxy policy.

Why is a proxy not suitable for forwarding QUIC traffic?

Problem 1: The TCP-over-TCP issue

Both TCP and QUIC are reliable transport protocols, which means that when they detect a missing packet during data transmission, they will automatically retransmit that packet.

Let’s look at what happens in a hypothetical scenario when a TCP-based proxy relays QUIC:

1. Data segment A is sent, which is encapsulated into QUIC UDP packet B, and then encapsulated again into TCP packet C when relayed through a TCP-based proxy.

2. The network jitters and packet C is dropped.

3. The TCP protocol detects the loss and retransmits packet C'2.

4. The QUIC protocol also detects the loss and retransmits packet B'2. From the TCP layer’s perspective, B'2 is new data and results in a new TCP packet D.

You can see that a single packet loss, which originally requires only one retransmission, results in double retransmissions due to the nesting of two reliable transport protocols. This is just the simplest case. If packet loss is heavy, the QUIC layer will generate a large number of retransmissions, and the TCP layer—trying to ensure that all QUIC retransmissions are delivered (even though they contain the same data)—will in turn generate a large number of retransmissions. This leads to congestion growing exponentially.

The above only describes one of many issues; there will also be doubled ACK packets and congestion control algorithms becoming ineffective, among others.

Therefore, QUIC should be avoided as much as possible over TCP-based proxies. However, if the TCP proxy itself has a very good route with almost no packet loss and the QUIC traffic volume is small, you may not notice obvious problems in practice. But in reality, unnecessary overhead is introduced, and performance is far inferior to using a pure TCP-layer proxy directly. So unless you need to test QUIC or have other development-oriented use cases, do not tweak the block-quic parameter to allow QUIC traffic.

Problem 2: QUIC flow-control opacity

Even when forwarding QUIC traffic over a UDP-based protocol, QUIC’s flow-control mechanism is opaque to intermediate nodes. The proxy server cannot introduce additional intermediate buffers for QUIC flows the way it can for TCP traffic. Under poor link quality, overall stability is often significantly worse than protocols based on TCP.

Therefore, allowing QUIC traffic may lead to a noticeable degradation in user experience, and is only recommended for users with very specific and clear requirements who manually enable it.

Why is MITM Prompted as Failed?

MITM is a tool used to decrypt HTTPS traffic and should be understood before use. For basic principles, refer to Wikipedia.

1. First, ensure that the CA certificate installation operation is completed (on iOS/tvOS/visionOS, in addition to installation, you need to manually turn on the switch in system settings).

2. Enable MITM for specific hostnames in Surge, like example.com.

3. Turn on the MITM switch in Surge.

4. Use a browser to visit the https://example.com/ website and see if the full URL and HTTP method can be decrypted.

If successful, it means MITM has been correctly configured and is effective.

If browser requests can already be decrypted correctly, but some app requests show MITM Failed, it indicates that the app has used SSL Pinning mechanisms to prevent MITM. Please search for relevant keywords to know more (in general, SSL Pinning can't be bypassed without complex hacking techniques, like injecting dylibs to overwrite related verification codes on jailbroken devices).

Many common applications, such as system processes sending requests to apple.com and icloud.com, Facebook, Instagram, etc., have adopted SSL Pinning mechanisms to block MITM.