Shadowrocket WireGuard Setup: PrivateKey, Endpoint, and AllowedIPs Explained

1. Understand Interface and Peer before adding a connection

A WireGuard setup in Shadowrocket can’t be completed with just a server address. A typical WireGuard configuration separates details into [Interface] and [Peer]: the former describes your device’s keys and tunnel address, while the latter describes the peer’s public key, endpoint, and allowed address ranges. If you swap the keys, authentication won’t work even if the address and port are correct.

This guide assumes you already have your own provider and configuration. Before adding a connection, make sure you have the complete set of matching parameters. An Endpoint alone, without your PrivateKey or the peer’s PublicKey, isn’t enough for a working configuration. Shadowrocket is a closed-source commercial app; buying the app is not the same as purchasing a network service, and the app does not generate a working WireGuard peer for you.

2. Add WireGuard from Home and keep the original parameters handy

To add a connection manually, go to Home → tap “+” in the upper-right corner → Type → WireGuard. Select the protocol before entering details so you don’t put WireGuard parameters into a form for another protocol. The standard field names from a WireGuard configuration are used below; the app may split Endpoint into separate address and port fields. Refer to the fields shown in your current version of the app.

1. Organize the configuration

   Keep a copy of the original configuration and identify Interface’s PrivateKey and Address, along with Peer’s PublicKey, Endpoint, and AllowedIPs. If there’s a PresharedKey, note it too, but don’t include it in public notes or screenshots.

2. Select the protocol

   Go to Home → “+” → Type → WireGuard. Confirm the Type first, then enter the parameters. Don’t paste the entire configuration file into the server address field.

3. Enter the endpoint

   Enter the Endpoint host and port in the corresponding fields. For example, 192.0.2.10:51820 means host 192.0.2.10 and port 51820. This documentation address can’t be used as a real endpoint.

4. Enter the identities

   Enter your PrivateKey, the peer’s PublicKey, and your assigned Address. Then set AllowedIPs and any optional parameters according to the original configuration. Don’t include quotation marks, field names, or line breaks with the keys.

5. Save and verify

   After saving, return to Home, select the configuration, check Global Routing, and start the connection. If iOS asks for permission to add a VPN configuration, verify the app and follow the system prompts. Send a request to a known accessible destination and check the result.

3. PrivateKey and PublicKey: Correct length doesn’t guarantee a match

PrivateKey authenticates your device. Its corresponding public key must be registered in the peer’s configuration on the remote end. The Peer PublicKey entered in Shadowrocket should belong to the remote peer. The two ends don’t exchange private keys: each keeps its own private key and uses the other end’s public key to identify the peer.

These lengths can help spot obvious copy errors, but they don’t prove that a key is valid or belongs to the same connection. A trailing = may be Base64 padding, so don’t remove it arbitrarily. Spaces, quotation marks, and line breaks added by chat formatting aren’t part of the key. Don’t try to fill in missing characters based on how they look.

• Using your own public key by mistake: If you entered your device’s public key as the Peer PublicKey, get the remote peer’s key from the original configuration rather than repeatedly recreating the connection.
• Changing only your private key: A new PrivateKey generates a new public key for your device. The remote end must register it too, or the identities won’t match.
• Missing the pre-shared key: If the original configuration uses PresharedKey, entering only the public and private keys isn’t enough. A mismatched PresharedKey will also prevent authentication.
• Reusing the same identity on multiple devices: When multiple devices use the same identity, the peer may update its endpoint based on the latest authentication data, causing the connections to interfere with each other. Ask whoever manages the configuration to assign a separate Peer and tunnel address to each device.

4. What Endpoint, Address, and AllowedIPs control

Endpoint is the outer address used to reach the peer; Address is the IP your device uses inside the tunnel. They aren’t interchangeable. For example, a public endpoint using port 51820 doesn’t mean your Address should include that port. WireGuard uses UDP. If the endpoint only allows TCP, entering the same port number won’t make UDP reachable.

At the WireGuard protocol level, AllowedIPs helps select the Peer for outgoing traffic and validates the source address claimed by traffic received from that Peer. It isn’t a list of website domains: you can’t enter example.com or put it directly in a DOMAIN-SUFFIX rule. If only the IPv4 default range is included, don’t assume IPv6 destinations are covered too.

• If Endpoint is a hostname, the hostname must resolve before a handshake can be sent to the peer.
• Don’t change the Address prefix length based on habit alone: /32 and /24 represent different address ranges.
• Expanding AllowedIPs won’t grant forwarding or access permissions the peer doesn’t already have. First confirm what the peer allows.

5. Global Routing and WireGuard settings operate at different levels

Shadowrocket first uses its traffic policy to decide where a request goes. WireGuard parameters then govern communication over the selected connection. In Global Routing, Proxy, Direct, Config, and Scene aren’t interchangeable with AllowedIPs: Proxy uses a proxy route, Direct connects directly, Config applies configuration rules, and Scene applies the configured scene settings. The outcome also depends on the selected policy and configuration.

For an initial test, you can briefly select Proxy and the WireGuard connection you’re testing, if you understand the impact, to reduce interference from rule-based routing. Restore your original setup after testing. Under Config, a request that matches DIRECT won’t automatically use that Peer just because AllowedIPs includes the default range, even if WireGuard itself is working.

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

This is an illustration of rule keywords, not a WireGuard configuration or a recommendation to replace your existing Config. DOMAIN-SUFFIX matches domain suffixes, GEOIP matches against an IP geolocation database, IP-CIDR matches IP ranges, and FINAL handles requests that don’t match earlier rules. PROXY in this example means a proxy policy. When using rules, also check where the policy in your configuration points; don’t rely on the final rule text alone.

6. When to adjust MTU and PersistentKeepalive

MTU controls the size of IP packets sent over the tunnel interface. WireGuard encapsulation adds overhead for the outer IP and UDP headers, so don’t simply copy the underlying link’s MTU into the tunnel. 1420 is a common troubleshooting reference, not a universal setting. Prefer the value in your configuration or the app’s default.

1. Check basic connectivity first. If there’s no handshake, check the Endpoint, UDP connectivity, and keys first. MTU shouldn’t be your first suspect.
2. Record reproducible symptoms. For example, if small requests work but larger responses repeatedly stall, investigate path MTU, packet loss, or related network restrictions. This is a troubleshooting clue, not proof of a specific cause.
3. Change one value at a time. If allowed by the configuration provider, compare 1420 and 1380. Save and reconnect after each change, test the same destination with the same request, and note the original value so you can restore it.
4. Don’t keep lowering the value. If a lower MTU doesn’t help, check DNS, routing, and peer status instead. For IPv6, the link MTU requirements must also be met.

PersistentKeepalive periodically sends keepalive packets to help maintain a NAT mapping. 25 seconds is a common example, not a protocol requirement; 0 disables periodic keepalives. It can help troubleshoot return traffic that stops after a period of inactivity, but it can’t fix a wrong public key, an unreachable port, or a destination range that isn’t allowed.

• The configuration uses seconds. Don’t enter 25 seconds as milliseconds.
• Not every network needs the same keepalive interval. Follow the configuration provider’s requirements and test the result.
• Retest after switching mobile networks. Keepalives can’t guarantee that every request will succeed during an IP address change.

7. Troubleshoot the symptoms instead of repeatedly rebuilding the configuration

Change only one setting per troubleshooting round, and record the test network, Global Routing mode, destination, and result. A latency or connectivity result on Home only reflects the test that was run. Different tests cover different parts of the connection, so a single latency number can’t prove that the keys, DNS, AllowedIPs, and all application traffic are working.