Shadowrocket WireGuard Setup: PrivateKey, Peer, and MTU Explained

1. Confirm which side each setting belongs to

Shadowrocket is a paid app for Apple platforms, primarily iPhone and iPad. It is available exclusively on the App Store. The developer is Shadow Launch Technology Limited, the app ID is 932747118, and it is a one-time purchase. Check the App Store listing for system requirements. Buying the app does not include a service plan; this site does not provide, sell, or recommend servers or subscriptions.

WireGuard uses keys to identify both ends of a connection. In a configuration, [Interface] usually describes your device, while [Peer] describes the remote end. Shadowrocket’s server editor is not a raw configuration-file editor, and fields may be displayed separately. Match each value to the field it describes; do not paste the entire configuration into a single field.

Before you start, obtain your device’s PrivateKey and Address, the remote PublicKey, the Endpoint, and any other settings required by your service provider. If the configuration includes a PresharedKey, keep it as well. A PublicKey or server address alone is not enough to configure a connection. The server must also have the PublicKey paired with your device’s PrivateKey and allow the corresponding tunnel address.

2. Add a WireGuard server from Home

Keep a copy of the original settings, then create a separate test entry. The steps below use English interface labels; field order may vary in the current app. Do not add a raw WireGuard configuration as a Subscribe link, or assume that settings for another protocol in an existing subscription can be converted directly to WireGuard.

1. Open the add-server screen

   Go to Home → tap “+” in the top-right corner → Type, then select WireGuard. Make sure you are editing a single server entry, not a Subscribe item.

2. Enter the remote endpoint

   Enter the host and port from Endpoint in the server address and port fields. For example, vpn.example.com:51820 means the host is vpn.example.com and the port is 51820. If the form has separate fields, do not add the port again in the host field.

3. Enter your device settings

   Enter PrivateKey and Address as shown in the original configuration. Address is your device’s tunnel address, not the Endpoint or your current Wi-Fi LAN address.

4. Check the Peer settings

   Enter the remote PublicKey in the corresponding field. Fill in PresharedKey only if it is explicitly included in the settings from your service provider. Do not substitute the PublicKey or add a random value.

5. Save and test

   Check MTU and any other available fields against the original settings, then save and return to Home to select the new entry. For an initial test, you can temporarily choose Global Routing → Proxy, then turn on the connection switch on Home. When prompted to create a system VPN configuration for the first time, confirm the request.

3. How PrivateKey, PublicKey, and Peer relate

The most common key mistake is not using the wrong length, but swapping the keys between the two ends. Keep PrivateKey on your device; the Peer’s PublicKey identifies the remote end. The server configuration needs your device’s PublicKey. Since each side’s Peer points to the other side, do not copy the server’s entire Peer section into your device’s Peer settings.

A standard WireGuard key is usually 44 characters in Base64 and ends with =. This can help identify truncation or copying mistakes, but does not confirm that the keys are paired correctly. Keep the final character when copying; remove any accidentally included spaces, line breaks, or quotation marks. Do not include a field name such as PrivateKey = in the value.

• Connection stops working after replacing PrivateKey: Changing the private key changes your device’s PublicKey. The new identity cannot communicate using the old settings unless the server’s registration is updated.
• Unreliable after copying to a second device: If multiple devices use the same key identity at once, the remote end may see the tunnel address change back and forth. Ask your service provider to assign a separate identity and address to each device.
• Connection stops working when PresharedKey is omitted: If the remote end requires this setting, your device must use exactly the same value. It is not an optional note that can be left out.

4. Keep Address, Endpoint, and AllowedIPs separate

Address describes your device’s address inside the tunnel; Endpoint describes the remote entry point outside it. In 10.7.0.2/32, the number after the slash is the CIDR prefix length, not a port. Do not change it to 10.7.0.2:32. If your service provider assigns both IPv4 and IPv6 addresses, enter each as provided; do not make up a similar-looking address.

The domains and addresses above illustrate syntax only and cannot be used to establish a connection. Do not add https:// to Endpoint or enter a subscription path. If the original Endpoint uses a domain name, it must resolve before the tunnel is established. This makes “which DNS is used after connecting” a separate question from “whether the Endpoint can resolve before connecting.”

In a native WireGuard configuration, AllowedIPs is used to select outbound traffic for a Peer and check inbound source addresses. Common client values such as 0.0.0.0/0 and ::/0 cover all IPv4 and IPv6 address ranges. A server’s Peer entry for a client often allows only the address assigned to that client. Do not mechanically use the same range at both ends. In Shadowrocket, whether app traffic is routed through this server also depends on Global Routing, the current Config, and the selected policy. AllowedIPs is not an in-app traffic-routing rule.

5. When and how to adjust MTU and PersistentKeepalive

MTU is not a bandwidth value. WireGuard encapsulation adds overhead, so the permitted packet size inside the tunnel must suit the network path. If the original configuration specifies an MTU, use that value first. If not, leave the app’s default handling unchanged. Do not change MTU, DNS, port, and keys all at once because a slow-loading webpage will not tell you which change had an effect.

• When to consider MTU: Consider path MTU as a possible issue only if the connection is established and small requests work, but larger responses consistently stall. Packet loss or a remote-side issue can cause similar symptoms, so one failed page load is not enough to draw a conclusion.
• How to test one variable at a time: Record the original value. If it is 1420, you could temporarily try 1380, if your service provider allows it, then reconnect and test the same destination. These values are test examples, not universal recommendations.
• How to handle IPv6: Do not randomly lower the MTU below 1280 as a test. IPv6 has a minimum link MTU requirement; if you use IPv6, check the server settings and actual network path as well.
• How to revert: Restore the original value if the change does not produce a repeatable improvement. Do not assume a value that works on one network will work for every device and network.

PersistentKeepalive periodically sends keepalive packets, commonly to maintain a NAT mapping; it does not increase bandwidth. In a raw configuration, PersistentKeepalive = 25 means a keepalive is sent about every 25 seconds. This is a common example, not a fixed Shadowrocket default. Fill it in only if the current interface has a corresponding field and your service provider requires it. Do not paste the entire line into another field.

6. Use Global Routing to distinguish protocol issues from rule issues

Saving a WireGuard entry only configures the server settings. Home is where you select and connect; Config contains routing rules; Settings includes options such as On Demand. To troubleshoot, keep the same server, destination, and network, then compare Global Routing options. If you switch servers, do not attribute every change in behavior to the rules.

Global Routing may also use Scene to switch routing settings based on context. Keep the option fixed during initial troubleshooting so that scene conditions do not change the test path. The following is a syntax example for the [Rule] section in Config, not a WireGuard server setting. Back up your current Config before testing; do not overwrite the entire configuration file.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Rules are matched in order: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP checks an IP geolocation database, and FINAL handles traffic not matched by earlier rules. In this example, requests to subdomains of example.com match the first line. All other traffic does not automatically go direct; it continues to the next rule. Check in the app which server the PROXY policy ultimately uses.

7. Share troubleshooting details without sharing private keys

After completing these steps, distinguish between “unable to establish effective communication with the remote end” and “tunnel traffic is flowing, but the destination is unavailable.” For the first, check the keys, Endpoint, and UDP reachability. For the second, check DNS, server forwarding, AllowedIPs, and MTU. WireGuard may not return a readable error for invalid requests, so the absence of a clear error in the interface does not mean every field is correct.

When contacting your service provider, you can share when the issue occurred, whether you were on Wi-Fi or cellular, the current Global Routing option, a redacted Endpoint, whether the traffic counters changed, and the results of one-variable tests. Do not share your PrivateKey, PresharedKey, full configuration file, or a subscription link containing credentials. If a key has been exposed, request a new identity and revoke the old configuration rather than simply renaming the entry.

• After testing, restore the original Global Routing option and confirm the current Config and selected server.
• If you need automatic connection, restore the settings under Settings → On Demand and test behavior on both Wi-Fi and cellular networks.
• Keep a record of necessary setting changes, but do not paste keys into public notes, screenshots, or public discussions.