Shadowrocket WireGuard Setup: Private Key, Peer, AllowedIPs & MTU

1. Distinguish the local interface from Peer

WireGuard identifies peers by public key and sends encrypted data over UDP. The local interface defines the device's identity and tunnel address; a Peer represents the remote endpoint. Keep the keys for each side separate: your device holds its own Private Key and uses the remote party's Public Key to connect. The remote side must register the Public Key corresponding to your Private Key.

This guide assumes you already have a valid configuration. This site does not provide, sell, or recommend nodes or subscriptions. WireGuard setup is not as simple as entering an address and a generic password: at minimum, verify the key pair, local tunnel address, and remote endpoint. Do not reuse authentication fields from Shadowsocks, VMess, VLESS, Trojan, or Hysteria2 in WireGuard.

In a standard WireGuard configuration, [Interface] and [Peer] describe the parameters. They are not Shadowrocket [Rule] sections. Before importing a configuration, confirm that its file format is supported by the app; matching file extensions alone do not make formats interchangeable.

2. What to enter for Private Key, Public Key, and addresses

Private Key is your device's secret credential. Copy it exactly from your existing configuration, taking care not to add spaces or line breaks or omit any characters. Changing the Private Key changes your device's identity. If the remote side still has the old Public Key registered, communication will fail even if the Endpoint is correct. Do not generate a new key just to see if it fixes a connection issue.

In Address, /32 denotes a single IPv4 address prefix; /128 is commonly used for a single IPv6 address. These addresses are determined by the remote network's design. Do not replace them with local network addresses just because they differ from your home Wi-Fi addresses. If the source configuration includes both IPv4 and IPv6, first confirm that the remote side and your current network support both.

3. Add and check WireGuard in Home

In Shadowrocket, Home is where you select a connection, Config manages rule configurations, and Settings manages app preferences. Get the WireGuard settings right before working on traffic routing. The field layout may change between app versions, so the steps below describe the general navigation. Names such as AllowedIPs and DNS from a source file may not appear as individual fields in the editor; do not put them into unrelated fields just because there is no matching input.

1. Gather your settings

   From your configuration, identify your Private Key, tunnel Address, remote Public Key, Endpoint, and optional Preshared Key. Keep an original copy for reference.

2. Choose the type

   Go to Home → “+” in the upper-right corner → Type → WireGuard. Select the type before entering the fields so you don't mistake another protocol's editor for the WireGuard setup screen.

3. Enter the endpoint

   Enter the Endpoint host and port in the corresponding server fields, such as Address and Port. For the documentation endpoint 192.0.2.10:51820, the host is 192.0.2.10 and the port is 51820. The server Address is not the same as the tunnel Address.

4. Check the keys

   Enter your Private Key and the remote Public Key, then verify the local tunnel address. If you have a Preshared Key, enter the value from your original configuration. If not, do not substitute a password or Public Key.

5. Save and test

   After saving, return to Home and select the connection, then check Global Routing. For the first test, use one specific destination. During troubleshooting, you can temporarily turn off automatic triggers in Settings → On Demand to prevent a manual disconnect from reconnecting automatically.

51820 is a common WireGuard listening port, not a port required by the protocol. If your original configuration specifies 443, use that UDP endpoint; this does not mean it supports TCP or HTTPS. If UDP is blocked on your network, entering a different port does not mean the remote side is listening there.

4. AllowedIPs and Global Routing operate at different levels

In standard WireGuard, AllowedIPs helps select a Peer for outgoing traffic and limits the source addresses accepted in decrypted traffic from that Peer. The common 0.0.0.0/0 prefix covers all IPv4 addresses, while ::/0 covers all IPv6 addresses. 10.7.0.0/24 covers only a specified subnet. AllowedIPs is not a domain list, website access permission, or paid usage allowance.

Shadowrocket also has routing layers in Global Routing and Config. Which app requests go through the selected connection depends on the current routing mode; seeing 0.0.0.0/0 in a source configuration does not prove that every request will use WireGuard. Scene lets you arrange settings for different scenarios. For basic troubleshooting, start with one clearly defined mode to reduce variables.

The following illustrates Shadowrocket rule syntax, not WireGuard configuration. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP subnets, and FINAL handles requests that did not match earlier rules. Rules are evaluated from top to bottom; requests already matched by an earlier rule do not continue to FINAL.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,DIRECT

Here, example.com and 192.0.2.0/24 are for documentation only. If you use GEOIP, note that it relies on an IP geolocation database and cannot replace checks of the Peer, AllowedIPs, or the server's return route. For more on rule behavior, see the rule reference.

5. MTU and DNS: two reasons a connection may still fail

MTU limits the size of IP packets carried by the tunnel interface. Encryption adds outer packet overhead, so tunnel MTU is usually lower than the underlying link MTU. 1420 is a common reference value, but it is not a universal setting for every Wi-Fi, cellular, or nested tunnel connection. Start with the value specified in your existing configuration or the default. Make controlled comparisons only if you see symptoms that point to an MTU issue.

These are diagnostic symptoms and test methods, not results from local testing. 1380 is not a universally optimal value either. If lowering MTU does not produce a repeatable improvement, restore the original value and check other layers. Do not change MTU, DNS, Endpoint, and routing mode at the same time, or you will not know which change made a difference.

DNS resolves domain names to addresses; it is not involved in the WireGuard public-key handshake. In a standard configuration, DNS is usually handled by the client software. Shadowrocket's actual DNS behavior also depends on the current Config settings. A DNS server reachable only inside the tunnel cannot handle all DNS lookups needed before the tunnel is established, especially if the Endpoint is a domain name.

• First confirm that the Endpoint domain resolves on your current network, then check whether the remote UDP endpoint is reachable.
• Do not test DNS only by opening an IP address in a browser: HTTPS certificates and virtual hosts may require the correct domain name.
• After changing DNS, reconnect and remember that system or app caches may affect comparisons.

6. Troubleshoot in this order: endpoint, handshake, data, rules

A connected status in the app or a VPN icon in the system only indicates the local connection state. It does not prove that the remote side accepted the keys or that a request reached its destination. WireGuard can remain quiet when there is no traffic, so trigger a specific request to test it. If you have remote administrative access, check the latest handshake time and transfer counters as well.

1. Endpoint: Verify the hostname or IP, confirm that the port matches the remote listener, and make sure the current network allows the required UDP traffic. Successful DNS resolution does not mean the UDP port is reachable.
2. Handshake: Confirm that the Public Key corresponding to your Private Key is registered on the remote side, that the remote Public Key is correct, and that both sides use the same optional Preshared Key. Matching-looking key lengths are not enough to verify a key pair.
3. Data: If the handshake succeeds but traffic does not, check the tunnel address, AllowedIPs, remote forwarding, firewall, and return route. Whether the remote side needs NAT or an explicit return route depends on its network design.
4. Rules: Compare the same request using Global Routing → Proxy and Config. If it fails only under Config, first check which rule matches and which policy it references; you do not need to replace the keys as a first step.
5. Stability: If the connection drops after being idle, check NAT mapping and whether keepalives are needed. In a standard configuration, PersistentKeepalive is measured in seconds; 25 is a common example, not a requirement for every connection. Change it only if your existing configuration calls for it and the app supports the setting.

7. Common configuration mistakes and a pre-save checklist

The most common manual setup errors are not about choosing from too few protocols; they come from mixing up field roles. Review each field before saving, especially when both the server address and tunnel address are labeled Address. If a WireGuard connection comes from a subscription, manual changes may be overwritten at the next update. Keep a separate record and check where the settings are managed.

• Entering your own Public Key as the Peer: The Peer Public Key belongs to the remote side. Give your own public key to the remote side for registration.
• Entering a web URL as the Endpoint: Do not include https:// or a web path. If the host and port have separate fields, enter them separately. Be especially careful not to split an IPv6 address arbitrarily at the colons.
• Omitting the tunnel address prefix: Keep the prefix from the original Address. If the app has separate fields, enter the values as requested without changing the assigned address.
• Using AllowedIPs instead of app rules: IP prefixes and DOMAIN-SUFFIX rules operate at different levels. Do not enter a domain in AllowedIPs.
• Treating Preshared Key as a login password: Leave it unset if your configuration does not include one. If it does, use the key agreed upon by both sides.
• Forgetting automatic connection settings: Settings → On Demand controls when connections are triggered; it does not change keys, Peer settings, or [Rule] content. Restore your automatic connection settings after troubleshooting.

After checking the configuration, first confirm that a specific destination can send traffic through the selected WireGuard connection. Then restore your Config routing and everyday automatic connection settings. Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. Check the App Store listing for pricing, system requirements, and compatibility with other Apple devices. Buying the app does not include a network service or connection configuration.