This guide is for users who already have their own WireGuard configuration from a provider. First, distinguish the local Interface from the remote Peer. Then follow the Add Server workflow to check addresses, ports, keys, and tunnel settings, and review AllowedIPs, Global Routing, and MTU separately. By the end, you’ll know which side each value belongs on and where to start when the connection is enabled but requests fail.
1. Identify Interface and Peer in the Configuration
WireGuard in Shadowrocket uses the WireGuard protocol to establish a tunnel. It transports traffic over UDP, with each side identified by keys; it does not use a username-and-password login. This guide assumes you already have a valid configuration. Use the configuration assigned to the device you’re setting up, and don’t combine fields from different devices or Peers.
A typical configuration file has two sections: [Interface] and [Peer]. The first describes the local tunnel interface; the second describes the remote peer. Go to Home → “+” in the top-right corner → Add Server → Type → WireGuard, then enter values according to what each field means—not by copying the file line by line. Form sections and optional fields may move as the interface changes.
| Section | Common fields | Before you fill it in |
|---|---|---|
[Interface] | PrivateKey、Address、MTU | Describes this client—not the server’s private key or public address. |
[Peer] | PublicKey、Endpoint、AllowedIPs | Describes the remote peer, where to connect, and which address ranges can be sent to that Peer. |
Optional [Peer] fields | PresharedKey、PersistentKeepalive | Fill these in only if they appear in the original configuration or your network requires them. |
| Name resolution | DNS | A name resolution setting—not the Peer’s public key or the Endpoint port. |
2. Enter the Address and Keys in Add Server
When adding a server, start with the remote address and port, then check the keys on both sides, and finish with the local address and advanced settings. These steps follow the entry workflow. If WireGuard-specific options appear in a separate section, match them by field meaning.
-
Choose the type
Go to Home → “+” → Add Server → Type → WireGuard. Select the correct Type before entering values so you don’t look for matching fields in another protocol’s form.
-
Split the Endpoint
Split the original Endpoint into the remote host for Address and the port for Port. For example,
vpn.example.com:51820is for illustration only: the host isvpn.example.comand the port is51820. Enter your own values. -
Check the keys
Enter the local Interface private key as PrivateKey and the remote Peer public key as PublicKey. If the original configuration includes PresharedKey, enter it in the corresponding field. Don’t use the client’s own public key as the remote public key.
-
Enter the tunnel settings
Enter the Interface Address as the local tunnel address. Preserve the address family and prefix as supported by the form, then check AllowedIPs, MTU, and optional PersistentKeepalive.
-
Save and test
After saving, return to Home, select the configuration you just added, and check Global Routing. On the first connection, approve the VPN configuration when prompted by the system. Then test with a request that you know will use this configuration.
Address depends on context. The general address field in Add Server usually refers to the remote server, while WireGuard’s Interface Address is the local tunnel address, such as 10.66.0.2/32. When transferring values, check which section a field belongs to; don’t put a private tunnel address in the remote server field. IPv6 Endpoints are commonly written in the original configuration as [2001:db8::10]:51820. The brackets separate the address from the port; they don’t indicate a local interface address.
PrivateKey, PublicKey, and PresharedKey are encoded key values, not ordinary passwords. WireGuard keys are 32 bytes and commonly appear as 44-character Base64 strings. A matching length can help catch missing characters, but it doesn’t prove that the keys are paired correctly. When copying, watch for the trailing =, hidden line breaks, and extra spaces.
3. What AllowedIPs and Global Routing Control
AllowedIPs is a set of address prefixes for a WireGuard Peer. It helps determine which Peer receives traffic for a destination and also limits which source addresses that Peer can use when sending traffic back. It is not a list of website domains: don’t enter example.com or paste an entire DOMAIN-SUFFIX rule into it.
Shadowrocket’s rule layer and WireGuard’s Peer layer make separate decisions. Global Routing determines how a request enters policy processing when you select Proxy, Direct, Config, or Scene. Once a request is routed to WireGuard, it must also match the Peer’s address ranges and the remote forwarding setup. Changing AllowedIPs alone does not mean all traffic in the app will use the tunnel.
| Setting | What it means | Limitations |
|---|---|---|
0.0.0.0/0 | Covers all IPv4 addresses. | Doesn’t include IPv6 or replace the Global Routing selection. |
::/0 | Covers all IPv6 addresses. | The remote and local configurations must also support IPv6. |
10.20.0.0/16 | Covers only the specified IPv4 subnet. | For a restricted subnet, this doesn’t mean public destinations will be reachable through that Peer. |
DOMAIN-SUFFIX、IP-CIDR、FINAL | A rule keyword used in Config. | Controls request policy selection. Put it in the rules configuration, not in AllowedIPs. |
In short: check both scopes separately
If a request to a public destination fails, first confirm that it actually selected WireGuard. Then check whether AllowedIPs includes the destination’s address family and subnet. Getting either layer right on its own is not enough to establish a working data path.
In Config mode, check the rule order in the active configuration and the policy that ultimately matches. Direct mode isn’t suitable for testing a WireGuard route. For Scene, check the settings for the active scene. To isolate rule-related issues, note the original settings, temporarily switch to Proxy and select the WireGuard configuration you’re testing, then restore the original mode afterward.
4. Choosing MTU, UDP Port, and Keepalive Values
MTU limits the size of IP packets sent through the tunnel, in bytes. Tunnel encapsulation takes up space in the outer packet, so the access network’s MTU cannot simply be used as the tunnel’s MTU. An MTU that’s too large may allow small requests while larger responses stall. DNS issues, remote forwarding, or packet loss can cause similar symptoms, so a page failing to load alone isn’t enough to identify the cause.
- MTU: Prefer the value provided by your service provider for the current network path. With an outer path MTU of 1500, WireGuard overhead is often estimated at about 60 bytes over outer IPv4 or 80 bytes over outer IPv6. 1420 is a common starting point, not a value that works on every network.
- Port: It must match the Endpoint. If the server uses a different UDP port, don’t change it to 51820 just because that’s the example. A successful webpage or TCP test doesn’t prove that UDP traffic to the same address is working.
- PersistentKeepalive: Sends periodic keepalive packets to help maintain a NAT mapping. A value of 25 in the original configuration usually means 25 seconds, not 25 milliseconds; 0 usually disables periodic keepalives.
- PresharedKey: An additional shared key that must match on both sides. If it isn’t in the original configuration, don’t generate one and enter it only on the client—that will cause a mismatch.
In short: change one variable at a time
After confirming the handshake and routing, if only large responses fail, note the original MTU and temporarily lower 1420 to 1380 for comparison. If that doesn’t help, restore the original value and continue checking the network path. This is a troubleshooting step, not a speed boost.
5. Troubleshooting from VPN Approval to Web Access
Turning on the connection switch on Home means the client has started handling the connection. It doesn’t mean WireGuard has completed a handshake or that DNS and remote forwarding are working. WireGuard typically handshakes on demand, so generate a request that definitely uses this configuration and check any available logs, statistics, or status from your service provider.
- Check VPN approval and selection: Make sure system VPN approval is complete and the WireGuard configuration you want is selected on Home, not another saved entry.
- Check the request path: Review Global Routing. In Config, check whether the request matches the expected policy. While troubleshooting, note the state of Settings → On Demand so automatic connection rules don’t interfere with observations when you disconnect and reconnect manually.
- Check Endpoint reachability: If the remote endpoint uses a domain name, first check that it resolves, then check whether the current network allows the configured UDP port. Switching between Wi-Fi and cellular can help identify network-specific issues; keep the same configuration during the test.
- Check the key pairing: Confirm that the local PrivateKey corresponds to the client public key registered on the server, and that the remote PublicKey belongs to the current Peer. If the settings look right but there is no successful handshake, ask whoever provided the original configuration to check the registered keys.
- Check traffic and DNS: If a handshake succeeds but requests get no response, check AllowedIPs, remote forwarding, and access permissions. If only domain names fail, then check the DNS path; don’t start by changing the MTU or keys.
6. Common Questions When Entering WireGuard Settings
Can I swap PrivateKey and PublicKey to test the connection?
No. Check the original configuration: Interface PrivateKey is the local private key, and Peer PublicKey is the remote public key. If you were given a server configuration rather than a client configuration, first get the client settings assigned to your device. Don’t simply swap the two values.
Why are some requests going direct even though AllowedIPs covers all addresses?
First check Global Routing on Home. In Config, rules determine whether a request goes to WireGuard; in Direct, a full-range AllowedIPs setting won’t send traffic through the tunnel. Check the policy matched by the active rules, then confirm that the IPv4 and IPv6 ranges are covered separately.
Should I enter the DNS from the original configuration in Address?
No. Address refers to a remote address or local tunnel address, depending on the section; DNS is a name server. Check the DNS settings in the active Config and how they can be reached. If the DNS server is on the tunnel’s private network, make sure requests can reach it through WireGuard.
It takes a long time to reconnect after I lock and unlock the screen. Will changing MTU help?
First check whether the NAT mapping may have expired while idle. Review PersistentKeepalive in the original configuration and see whether the handshake resumes when you make another request. MTU controls packet size; it doesn’t maintain NAT mappings. If the connection still fails after switching networks, check the Endpoint and UDP path.
When keeping troubleshooting notes, record only the network type, Global Routing mode, destination address family, MTU, and the stage where the failure occurs. This makes it easier to distinguish “no handshake,” “handshake succeeds but no traffic,” and “only domain names fail,” without repeatedly changing keys, routing, and DNS settings at the same time and losing a reliable basis for comparison.