Surge FAQs
Last updated
Last updated
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 2% in 24 hours, so there is no need to worry.
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:
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.
If requests are not displayed in the Surge request viewer, you can troubleshoot in the following order:
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.
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.
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:
Open Surge Mac's settings interface, select System Permissions Overview, and click Remove Helper.
Enter your system login password.
Click Open Terminal.
Enter your system login password again in the terminal window and press Enter.
Restart the computer.
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.
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:
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.
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.
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
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:
Create a copy of the managed profile, which will unlink the new profile from the original's automatic updates, allowing you to edit freely.
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
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.
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:
Create a copy of the managed profile, which will unlink the new profile from the original's automatic updates, allowing you to edit freely.
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.
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).
Enable MITM for specific hostnames in Surge, like example.com.
Turn on the MITM switch in Surge.
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.
For the specific differences in takeover methods, please refer to .
MITM is a tool used to decrypt HTTPS traffic and should be understood before use. For basic principles, refer to .