Shadowrocket WireGuard Setup: Private Key, Peer Public Key, and MTU Explained

At a glance

This guide is for users who have obtained WireGuard configuration details from their own provider and are ready to enter the fields manually in Shadowrocket. First, distinguish the local Interface from the remote Peer, then match the private key, public key, tunnel address, and endpoint. Finally, check the MTU and routing settings. Addresses, domains, and ports shown here illustrate the format only and cannot be used as a working configuration.

1. Understand which settings belong to Interface and Peer

A WireGuard configuration in Shadowrocket contains two kinds of information: the identity and address used by this device in the tunnel, and the remote endpoint it connects to. A typical WireGuard text configuration uses [Interface] and [Peer] sections. When entering settings manually, match each value to the corresponding field rather than pasting lines in the order they appear.

Private Key belongs to the local device's identity; the Peer Public Key identifies the remote end. Address is the device's address inside the tunnel, while Endpoint is the server's domain name or IP address and port on the network. These fields are not interchangeable.

Field ownership: local Interface and remote Peer

Interface (local device)

PrivateKey: the local private key, tied to this device's identity.
Address: the device's IPv4 or IPv6 address inside the tunnel.
MTU: the IP packet size supported by the tunnel interface.
DNS: resolver details to use with the configuration, if provided.

Peer (remote endpoint)

PublicKey: the remote public key, not the local device's public key.
Endpoint: the remote host address and UDP port.
PresharedKey: an optional shared key agreed upon by both ends.
AllowedIPs: tunnel routes and address constraints for this Peer.

Identify which side each field belongs to before entering its value. Do not put the local public key in the Peer Public Key field.

Your provider may supply a complete text configuration, a QR code, an entry in an existing subscription, or a set of individual parameters. The steps below focus on manual entry. Available fields depend on the current app interface. If there is no dedicated field for a parameter, do not put it in a similarly named field with a different meaning; confirm that the configuration is compatible with the import method you are using.

2. Add a WireGuard server from Home

Keep a complete copy of the original configuration before entering anything. If the provider's dashboard shows only the local public key and not the private key, you do not yet have everything needed to configure that identity. A public key cannot be used to derive a private key.

Prepare the original configuration

Get the complete set of parameters from your provider. Find the Interface PrivateKey and Address, along with the Peer PublicKey and Endpoint. Keep the PresharedKey too, if one is provided.
Select the protocol

Go to Home → tap “+” in the top-right corner → Type → WireGuard. Make sure you are creating a WireGuard entry, not pasting the entire configuration into a standard server address field.
Enter the endpoint

Enter the host portion of Endpoint in Address (server address) or the corresponding host field, and enter the port in Port. For example, split the fictional endpoint wg.example.com:51820 into wg.example.com and 51820. Do not add a web protocol prefix.
Enter the identity details

Enter the local Private Key, remote Public Key, and tunnel address in the corresponding WireGuard fields. If there is a Preshared Key field, fill it in only if the original configuration includes one. Do not substitute another key.
Save and verify

After saving, return to Home, select the entry you just created, and turn on the connection. Note the current Global Routing selection and the network used for testing. Verify an actual request to a destination you are authorized to access; do not rely only on whether the connection switch is on.

3. Private Key, Public Key, and PresharedKey

WireGuard private and public keys have a defined encoding format. They are typically Base64 strings representing 32 bytes, and are commonly 44 characters long. A matching length can rule out some copy errors, but it does not prove that a key belongs to the current server or that both ends are authorized.

The local private key can generate the local public key, which the server typically uses to identify this client. Generating a new private key on the device also changes its corresponding public key. If the server still has the old public key on file, the handshake will not work with the original identity. Do not treat “generate new keys” as a universal fix.

Field	What to enter	Common mistakes
`Private Key`	The private key assigned to this device's identity, usually from the Interface section.	Copying the local public key or using the private key for another device.
`Public Key`	The remote Peer public key, usually from the Peer section.	Entering the local public key or pasting the entire `PublicKey =` prefix as well.
`Preshared Key`	The additional symmetric key specified in the original configuration; both ends must use the same value.	Generating one when the original configuration has no such field, or using an account password instead.

When copying a value, take only what comes after the equals sign. Remove leading and trailing spaces and line breaks, but preserve every character in the key, including a possible trailing =. Do not treat + in the encoded value as a space or change the capitalization. A key is not a username, login password, or subscription link.

Treat Private Key and Preshared Key as sensitive credentials. Do not include them in public screenshots or the body of a support request.
When reporting a problem, provide the field names, symptoms, and redacted address types. You do not need to share the full private key.
If a private key is exposed, ask your provider to revoke the old identity and issue a new one. Renaming the entry does nothing to improve security.

4. Where to enter Address, Endpoint, and DNS

The Interface Address usually includes a CIDR prefix length, such as the fictional value 10.66.0.2/32. Here, /32 indicates a single IPv4 host address; a single IPv6 address commonly uses /128. This is not a port or the server's public address. If the interface has separate fields for the address and prefix, enter each part accordingly. Do not put the number after the slash in Port.

Fictional local-side example

Address: 10.66.0.2/32
IPv6 Address: fd42:66::2/128
DNS: 10.66.0.1
MTU: 1420, shown for illustration only

These values illustrate the structure of local fields only; they do not indicate how your provider assigns parameters.

Fictional remote-side example

Endpoint: wg.example.com:51820
Host: wg.example.com
Port: 51820, UDP port
IPv6 Endpoint: [2001:db8::10]:51820

For a full IPv6 endpoint, square brackets separate the host from the port. When entering the values in separate fields, follow the interface's expected format.

WireGuard uses UDP. 51820 is a common example port, but not every service uses it; use the port in your original configuration. If your current network cannot reach that UDP port, changing the number to 443 will not make the connection work unless the remote end is actually serving on that port.

DNS involves two separate stages. If Endpoint is a domain name, it must resolve before the tunnel can be established. Domain requests inside the tunnel are affected by Shadowrocket's current DNS and configuration settings. The DNS entry in the original WireGuard text is resolver information for that configuration; do not assume its DNS line is automatically applied when you create a server entry manually.

If Endpoint fails to resolve, first check the domain spelling, DNS resolution on the current network, and whether the host provided by your provider is valid.
Before specifying a DNS address inside the tunnel, confirm that the tunnel works and that the address is reachable through it.
If you use an IPv6 address, confirm that both the current configuration and the remote end support it. Entering an IPv6 address does not add IPv6 support on the remote end.

5. What MTU means and how to adjust it

MTU (Maximum Transmission Unit) determines the size of IP packets the tunnel interface can carry. WireGuard encapsulation adds overhead, so tunnel MTU is usually lower than the underlying link MTU. With a common underlying MTU of 1500, outer IPv4 encapsulation adds about 60 bytes, while outer IPv6 adds about 80 bytes. 1420 is one common value, but it will not suit every network path.

An MTU that is too high can cause small requests to work while larger responses stall or some webpages load incompletely. These are clues to investigate, not definitive evidence of an MTU problem. DNS, the remote exit, UDP packet loss, and rule selection can cause similar symptoms. Check the keys and endpoint before adjusting MTU.

Use the MTU specified by your provider

Recommended

If the original configuration specifies an MTU, use that value first. If it does not, leave the app's default handling in place and establish a reproducible connection baseline. Do not change several parameters at once based on guesswork.

Best for: first-time setup, a specified MTU, or a connection that works as expected

Use 1420 as a comparison

Use 1420 as a controlled test only when diagnosing an issue and the interface allows you to set it. It is a common tunnel MTU, not a speed setting, and it is not guaranteed to suit your current path.

Best for: no specified MTU and a need to compare one variable at a time

Temporarily lower it to 1380

If small requests work at 1420 but larger transfers repeatedly stall, try 1380 as a temporary comparison. Reconnect after each change and test the same destination. If there is no improvement, restore the original value.

Best for: investigating the network path after ruling out basic configuration errors

Record four details for a useful comparison: network type, MTU, test destination, and success or failure. For example, test 1420 and 1380 on the same Wi-Fi network, then repeat on cellular. This is a testing method, not a measurement of any particular connection in this guide. Do not assume that one successful webpage load identifies the best MTU, or use a single speed test as your only measure.

6. AllowedIPs and Global Routing are separate settings

In a standard WireGuard configuration, AllowedIPs defines tunnel routes for a Peer and restricts the source addresses accepted from it. For example, 0.0.0.0/0 represents all IPv4 addresses, and ::/0 represents all IPv6 addresses. It is not the same as Shadowrocket's domain rules and should not be pasted into the Rule section.

At the app level, Shadowrocket also determines which requests are sent through the selected server. Even with a correct key and Endpoint, requests will not use the WireGuard entry as expected if Global Routing is set to Direct. Config uses the rules in the currently enabled configuration, so check where the matched policy ultimately routes the request.

Proxy: Handles intercepted app requests using proxy routing. This can help distinguish server issues from routing issues, but does not mean all system traffic on the device follows the same path.
Direct: Handles requests without proxy routing. This is not a reliable way to verify that the selected WireGuard exit is working.
Config: Selects a policy using the current configuration's rules. Selecting a WireGuard entry does not mean every request will use it.
Scene: Applies the routing arrangement for the configured scene. When troubleshooting, check which scene is actually selected rather than relying on the routing mode name alone.

The following shows rule syntax only; it is not a complete configuration ready to enable. PROXY must refer to a policy or policy group that is actually available in your current configuration, and that policy must ultimately select the intended WireGuard entry. Rules are matched from top to bottom; the first matching rule determines how a request is handled.

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

DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches a destination address range; GEOIP matches according to an IP geolocation database; FINAL handles requests that do not match any preceding rule. The documentation address ranges in these examples illustrate syntax and are not real service destinations.

7. What to check if it still does not work after saving

Check in this order: “Are all fields present? → Can the endpoint be reached? → Do the key identities match? → Are requests routed through this server? → DNS and MTU.” Change one variable at a time and keep a record of the original value. An enabled connection switch only indicates that the local connection function has started; it does not by itself prove a successful handshake or a working exit.

Private Key is entered, but why doesn't it work?

Go to Home → open the edit screen for the entry and check that you copied only the key value, with no leading or trailing spaces. Then confirm that Peer Public Key is the remote public key. If you generated a new local private key, ask your provider whether the registered client public key was updated to match. Do not keep generating new keys to troubleshoot.

The switch is on, but nothing has changed?

On Home, confirm that the new WireGuard entry is selected, then check Global Routing. If you use Config, open Config and confirm which file is enabled, then check the policy matched by your test destination. You can use Proxy briefly for comparison; restore your original routing settings after troubleshooting.

Wi-Fi fails but cellular works. What should I check first?

Keep the keys and tunnel address unchanged. First compare Endpoint domain resolution, reachability of the specified UDP port, and network restrictions. Check MTU only if you see signs such as small requests succeeding while larger transfers stall. Do not change the keys, DNS, and port at the same time as switching networks.

Can I use the same configuration on two devices?

First check whether your provider assigns a separate identity to each device. If two devices use the same private key and tunnel address at the same time, the remote end may redirect the Peer’s reply endpoint to whichever device sent a packet most recently, causing the connections to interfere with each other. For simultaneous use, obtain a separate key pair and address for each device.

Checklist for saving your configuration

Keep the original configuration and notes identifying the device it belongs to. Store sensitive keys in a protected location.
Record the server host, UDP port, tunnel address, and verified MTU. Do not share complete credentials.
If the entry comes from an existing subscription, check whether updates will overwrite manual changes. Do not treat temporary diagnostic values as new parameters from your provider.
After testing, restore your original Global Routing and On Demand settings, then verify everyday access again.

Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. The App Store is the only way to get it; check the App Store listing for system requirements. A one-time app purchase does not include a network service plan. This guide assumes you already have your own provider and configuration; purchasing the app does not supply a Private Key, Peer public key, or remote server details.