Shadowrocket WireGuard setup: what each parameter means, from PrivateKey and PublicKey to Endpoint and MTU

First, distinguish Interface from Peer

WireGuard is a UDP-based encrypted tunneling protocol. Instead of a traditional username and password, it uses keys to identify the two parties. When you choose WireGuard in Shadowrocket, you need matching client and server parameters; a server address alone is not enough to complete the setup.

A typical WireGuard configuration file uses [Interface] for the local tunnel interface and [Peer] for the remote peer. “Local” means the current device; the “peer” is usually a server provided by a service you already use. In the client configuration, PrivateKey belongs to the current device, while the PublicKey under [Peer] belongs to the server. They are not the same key pair.

A native WireGuard configuration file and a Shadowrocket configuration file are different formats. You cannot use [Interface] or [Peer] from the former as Shadowrocket [Rule] rules. When adding a connection manually, map each value to the corresponding field in the WireGuard editor. If a client does not show every option from the native file, that does not mean you can put the remaining values into unrelated fields.

Key parameters: PrivateKey, PublicKey and PresharedKey

PrivateKey is the local private key and must be kept secret. It is usually Base64-encoded text: a 32-byte key typically encodes to 44 characters, including the trailing =. When copying it, do not include the field name, quotation marks, spaces or line breaks, and do not try to decode it as a URL. The right length only suggests that the format may be valid; it does not prove that the key matches the record registered on the server.

PublicKey is the peer’s public key and identifies the communication partner. The client’s own public key is derived from its private key and registered under the corresponding Peer on the server. The peer public key required in the client editor comes from the server. Putting the client’s own public key in the peer field—or entering the server’s public key as the private key—will prevent the handshake from establishing correctly.

PresharedKey is an additional symmetric key; it does not replace the public/private key pair. If your existing configuration does not include one, leave it unset. If the server has enabled it, leaving it out or entering it incorrectly will cause the handshake to fail. Do not generate a value just to fill every field, and never copy PrivateKey into PresharedKey.

• After regenerating the client’s private key, the server must be updated with the corresponding client public key. Changing only the local key usually will not restore the connection.
• Use separately registered keys and tunnel addresses for each device. Using the same identity on two devices can cause the peer address on the server to switch back and forth.
• Before sharing troubleshooting screenshots, cover the entire private key and preshared key. Never post a complete configuration containing keys in a public forum.

Endpoint vs. Address: the public endpoint is not the tunnel address

Endpoint is the server address contacted first to establish the tunnel. In 192.0.2.10:51820, 192.0.2.10 is a documentation-only example address and 51820 is the UDP port. If Shadowrocket shows separate address and port fields, enter them separately; do not paste the full address-and-port string into the address field. Do not add https:// before the address or a webpage path after it.

If the Endpoint is a hostname, it must resolve first, and the corresponding UDP port must be reachable over your current network. Being able to open a webpage or pass a TCP port test does not prove that the UDP endpoint is reachable. IPv6 addresses combined with a port need square brackets, for example [2001:db8::10]:51820. If the editor has a separate address field, follow its format instead of copying the brackets from the combined form.

Address is the address assigned to the client inside the tunnel and may include both IPv4 and IPv6. Keep the prefix length supplied by your provider, such as /32 or /128. Do not replace it with /24 just because that prefix is common on home networks. Address conflicts, unregistered addresses or addresses outside the server’s allowed range can leave data traffic blocked even after the handshake succeeds.

What AllowedIPs, DNS and MTU control

In WireGuard, AllowedIPs is associated with a peer’s tunnel address ranges and is used to select an outbound peer and validate inbound sources. 0.0.0.0/0 covers all IPv4 destinations, while ::/0 covers all IPv6 destinations. This does not guarantee that the server provides dual-stack forwarding, nor does it mean every Shadowrocket request will use this WireGuard connection. The client’s routing mode and configuration rules still determine which policy handles each request.

DNS resolves domain names to addresses; the tunnel transports data. In native configurations, DNS is often applied by the configuration manager and is not part of the WireGuard handshake itself. When entering values manually in Shadowrocket, also check the DNS settings in the current configuration. The presence of a DNS line in the original file alone does not mean the app is using the same resolution path.

• Only domain names fail: If the destination is reachable by address but domain lookups fail, first check whether DNS requests receive a response and whether the resolver is reachable.
• Only IPv6 fails: Check the IPv6 Address, ::/0 and the server’s IPv6 forwarding capability. Simply adding a route range does not guarantee full IPv6 support.
• Handshake succeeds, but traffic fails: Check the tunnel Address, AllowedIPs and server-side forwarding. Do not start by repeatedly replacing keys.

MTU is the maximum IP packet size carried by the tunnel interface in one transmission. WireGuard also needs room for the outer IP, UDP and encryption headers. Without additional encapsulation, the overhead is typically about 60 bytes over IPv4 and 80 bytes over IPv6. So, for an underlying path MTU of 1500, 1420 is a common reference value—but it is not a universal setting for every network or a fixed Shadowrocket default.

Keep the MTU specified in your existing configuration whenever possible. If small requests succeed but large webpages or uploads stall, record the original value and test one change at a time—for example, reduce 1420 to 1380 and retry the same request. This is a way to investigate path MTU issues, not a measured result for a particular network. If lowering the MTU makes no difference, restore the original value and continue troubleshooting other layers.

Add and test a connection in Shadowrocket

The steps below focus on manually adding WireGuard from Home. Editors may split or combine fields across platforms, so match them by meaning rather than by the number of rows. Save a copy of the original configuration first, verify the minimum setup, then adjust routing, DNS or MTU. Changing too many things at once makes it harder to identify the cause.

1. Check the original configuration

   Read [Interface] and [Peer] separately. Confirm that you have the local PrivateKey and Address, plus the server PublicKey and Endpoint. Check whether PresharedKey is present; do not invent missing parameters.

2. Choose the protocol

   Go to Home → tap “+” in the top-right corner → Type → WireGuard. Make sure you are editing a WireGuard connection; do not enter these parameters under another protocol type.

3. Enter the parameters

   Map the values to the local Interface and remote Peer fields. If Endpoint has separate address and port fields, enter each value in the appropriate field. Copy keys in full and retain the Address prefix length. Do not put values for unavailable optional settings into other fields.

4. Save and select

   After saving, return to Home and select the connection you just added. Note the current Global Routing mode. To temporarily rule out the effect of configuration rules, use Proxy for a one-time test, then restore your usual settings when done.

5. Test and take notes

   Start the connection and approve the VPN configuration prompt if your system asks. Test domain access, a small request and a larger download separately; note the network type, symptoms and any changes made. If automatic connection conditions are set under Settings → On Demand, check them during troubleshooting so they do not interfere with manual switching.

Distinguish WireGuard entries in a subscription from entries added manually. Updating a subscription you already use may change remotely managed entries; a temporary local edit is not a reliable source for a lasting configuration. If an entry stops working after an update, first compare its Endpoint, PublicKey and Address with the previous values. Then decide whether to re-import your own configuration.

Global Routing modes and troubleshooting

In Shadowrocket, correct protocol parameters and whether traffic actually uses the connection are separate concerns. WireGuard defines how the tunnel is established; Global Routing and the rules in Config determine which path a request takes. Do not treat a website opening as proof that WireGuard is connected: the request may have used DIRECT.

If you use Scene, first check which routing settings the active scene actually uses; the scene name alone is not a protocol test result. In Config, DOMAIN-SUFFIX, IP-CIDR and GEOIP are different matching conditions, while FINAL is the fallback at the end. During troubleshooting, check which policy handled the request rather than simply looking for the word WireGuard in the rules file.

Change only one variable at a time while troubleshooting, and keep track of the steps that reproduce the issue. A single latency test cannot replace checks of the handshake, DNS and actual traffic. Likewise, an enabled connection switch does not prove that the server accepted the current key. If you contact a provider you already use, share the time of the issue, network type, Endpoint port and symptoms. Do not send your private key or preshared key.