This guide is for users who already have a WireGuard service and configuration and want to check the settings in Shadowrocket. First, distinguish the local and remote identities, then match Address, Endpoint, DNS, and MTU. Finally, test the connection, routing rules, and web access separately. The focus is on who provides each setting and what can go wrong if it’s incorrect—not on providing a ready-to-use service configuration.
First, distinguish Interface from Peer
WireGuard settings in Shadowrocket must come from a complete configuration for a service you already use. A standard WireGuard file uses [Interface] for the local interface and [Peer] for the remote peer. When entering settings manually, map both sections to the same WireGuard profile. Don’t combine another device’s Private Key, this device’s Address, and a Public Key from a different server.
WireGuard carries tunnel traffic over UDP. The server address and port determine where packets are sent; the keys determine whether the two endpoints can authenticate each other. So “the address resolves,” “the port is correct,” and “authentication succeeds” are three separate checks.
Private Key, Public Key, and Preshared Key
In [Interface], PrivateKey is the local private key, shown as Private Key in the app. The corresponding local public key is derived from it and must be registered on the remote side. Your private key is neither a login password nor the remote public key. If you replace it without updating the corresponding entry on the remote side, the existing configuration can no longer communicate properly.
| Configuration field | What to enter | Common mistake |
|---|---|---|
Interface.PrivateKey | The private key held by this device; maps to Private Key. | Entering the server’s public key, or copying extra spaces or quotation marks. |
Peer.PublicKey | The remote peer’s public key; maps to Public Key. | Entering this device’s public key, so the remote identity doesn’t match. |
Peer.PresharedKey | An additional shared key agreed on by both sides; maps to Preshared Key. | Setting it on one side but not the other, or using different values. |
Public Key must be the peer’s public key, not “the public key derived from this device’s Private Key.” If the service configuration lists both a client public key and a server public key, check which section each belongs to: the PublicKey under [Peer] is the remote identity to verify here.
Preshared Key is optional, but that doesn’t mean you can remove it unilaterally. If it’s present in the original configuration, keep it exactly as provided; if it’s absent, don’t generate one yourself. Copy Base64 text containing +, /, or = in full. Don’t URL-encode it or remove a trailing = as if it were stray punctuation.
Address and Endpoint are different layers
Address is the IP address assigned to this device inside the tunnel, usually with a CIDR prefix length. For example, 10.66.0.2/32 is an IPv4 interface address; a dual-stack configuration may also include an IPv6 address such as fd00:66::2/128. These are syntax examples only and don’t replace the values assigned by your service. Address is not the remote server address or your device’s current Wi-Fi LAN address.
- Address: Enter the value from the original configuration, including prefix lengths such as
/32or/128. If the app has separate fields for IPv4 and IPv6, enter each in the corresponding field rather than combining them. - Endpoint: The reachable remote hostname or IP address and UDP port. The documentation address
192.0.2.10:51820is only an example of the format, not a connection endpoint. - Separate port fields: If the app shows separate Address and Port fields, enter the server address without a port and fill in Port separately. Don’t replace the port in your original configuration just because examples often use
51820. - IPv6 Endpoint: In standard configuration text, an IPv6 address with a port uses square brackets, for example
[2001:db8::10]:51820. When entering it into separate fields, follow the format required by the address field.
A standard configuration may also include AllowedIPs. It defines the address ranges associated with a WireGuard peer and is used for WireGuard routing and source-address checks. It is not Address and should not be treated as Shadowrocket’s global routing rules. Whether the editor provides a corresponding option depends on the fields shown in your version. Seeing 0.0.0.0/0 does not mean every Shadowrocket request will necessarily use this profile.
DNS and MTU: Check name resolution and packet size separately
DNS resolves domain names to addresses; it doesn’t fix incorrect keys. In standard WireGuard files, DNS is a configuration convention used by client tools, not an authentication parameter in WireGuard’s handshake. In Shadowrocket, also check which DNS settings are active in Config and Settings. A DNS address in the original file alone doesn’t prove that it’s being used at runtime.
| Setting | What to check | What you may observe |
|---|---|---|
DNS | Whether the resolver is reachable and accessible through the tunnel, and whether the Endpoint hostname can be resolved first. | Domain lookups fail, but a connection test to a known destination may still respond. |
MTU | Start with the original configuration; check whether encapsulating traffic in the tunnel exceeds the packet size the actual path can handle. | Small requests work, but large responses or uploads stall, or some pages load indefinitely. |
PersistentKeepalive | Whether the original configuration requires periodic keepalive packets and whether the current network’s NAT mapping is expiring. | The first request after a long idle period fails, then works briefly after reconnecting. |
MTU is measured in bytes. 1420 is a common reference value, not a universal optimum. If the original configuration specifies an MTU, test with that value first. Change only this setting if you can reproduce symptoms such as large requests stalling while small ones work. For example, try lowering 1420 to 1380, then retest the same page or upload and record the result. If there’s no improvement, restore the original value. Don’t change DNS and routing rules at the same time.
In the original configuration, PersistentKeepalive = 25 means a keepalive interval of 25 seconds, not a timeout or retry count. Whether keepalive is needed depends on the network and service configuration. It can’t replace correct keys, Endpoint settings, or a working UDP path.
Enter settings in Home and verify each layer
Home manages connection profiles, Config manages routing configurations, and Settings manages app preferences. Entering WireGuard settings and importing a routing configuration are separate tasks: the former defines how to connect, while the latter determines which requests use that connection. The way individual fields are displayed may vary in the current app interface. Match configuration fields to app fields by meaning, not by position in a list.
-
Get the original configuration
Keep the original configuration provided by your existing service, and confirm that Interface and Peer belong to the same device. Note the current Global Routing setting so you can restore it after testing.
-
Choose a connection type
Go to Home → tap “+” in the upper-right corner → Type → WireGuard. To edit an existing profile, open it from Home instead of creating multiple profiles with similar settings.
-
Match the settings
Map Endpoint to the server address and Port, Interface.PrivateKey to Private Key, and Peer.PublicKey to Public Key. Check Address, Preshared Key, and MTU against the original configuration and the fields shown in the editor, then save.
-
Isolate routing rules
Return to Home, select the saved WireGuard profile, and temporarily set Global Routing → Proxy. Turn on the connection and test a known-reachable HTTPS page. This helps reduce interference from Config rules, but you should still check DNS and other active settings.
-
Restore your usual settings
After basic access works, restore the original Global Routing setting and test the same destination again. If Settings → On Demand is enabled, temporarily turn off automatic connection triggers while troubleshooting to prevent a reconnect after manual disconnection. Restore the original setting when testing is complete.
An enabled connection switch only shows that the local connection process has started; it doesn’t by itself prove that the remote side completed a WireGuard handshake. A latency result also can’t replace a web access test: the test target, method, and actual request path may differ. Check domain resolution, access to the destination, and any available connection logs together.
How Global Routing affects test results
The following compares three routing modes in Shadowrocket to explain why test results can differ. Global Routing may also show Scene, but this guide doesn’t use it as the baseline for an isolated test. The recommended Config option means using checked rules for everyday routing; it doesn’t mean every configuration file will work as-is.
Config
RecommendedHandle requests according to the rules and policies in the current Config. The first matching rule determines the result, so a working WireGuard profile doesn’t mean every domain will use it.
Best for: Everyday rule-based routing after the basic connection has been verified
Proxy
Route traffic through the proxy. This can temporarily reduce the impact of ordinary routing rules. Before testing, confirm that the selected profile is the WireGuard profile you’re checking.
Best for: A brief isolated test after entering the settings for the first time
Direct
Access the destination directly. If a page opens in this mode, that doesn’t prove the WireGuard settings are correct. Record the result separately from a test to the same destination using Proxy.
Best for: Comparing with direct access on your current network
If only some destinations fail after you return to Config, check the rule order and the policy actually selected for each match. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches against an IP geolocation database, and FINAL provides the final action for requests that don’t match earlier rules. Don’t keep changing your Private Key to troubleshoot a rule-matching issue that occurs only in Config.
Common configuration issues and troubleshooting steps
Why can’t I connect even after entering the Private Key?
Open the profile’s edit screen from Home and check Type, Endpoint address, Port, Private Key, and the peer’s Public Key in order. Then confirm that the remote side has registered the local public key derived from this Private Key. If a Preshared Key was provided, both sides must use the same value. Checking only the number of characters in the private key isn’t enough.
Can I enter the server IP as Address?
No. Address is the local IP assigned inside the tunnel by the service; the server’s public address belongs in Endpoint. Restore the value from Interface.Address in the original configuration, including its prefix length. If you don’t have an Address value, confirm it with the provider of your existing service.
What if Wi-Fi works but cellular data doesn’t?
First, test both networks using the same profile, Global Routing setting, and destination to rule out changed test conditions. Then check whether the Endpoint is reachable over IPv4 or IPv6 and whether UDP traffic can pass. If the problem occurs only after the connection has been idle, check PersistentKeepalive in the original configuration. If only large requests fail, test MTU separately.
Why did my manual changes disappear after a subscription update?
Profiles managed by a subscription may have their settings overwritten during an update. First check whether you’re editing a manual profile or one generated by a subscription. Note which fields were overwritten and check the configuration returned by the subscription source. For a lasting fix, keep the settings consistent with the original configuration from your existing service rather than blindly repeating the same edits after every refresh.
Will lowering MTU fix every loading problem?
No. First check whether the destination is reachable with Proxy, then confirm that DNS resolution works. Only repeatable symptoms involving large packets justify further MTU testing. Lowering MTU won’t automatically fix mismatched keys, an incorrect port, or unreachable DNS.
After troubleshooting, record the network used, Global Routing setting, test destination, changes made, and results. When reporting an issue to the provider of your existing service, describe symptoms such as “the same destination fails with Proxy but works with Direct” or “small requests work, but uploads stall.” Be sure to hide keys and personal configuration details. Clear comparisons are more useful for troubleshooting than sharing the full configuration publicly.