Shadowrocket WireGuard Setup: PrivateKey, PublicKey, AllowedIPs & More

At a Glance

When setting up WireGuard, distinguish your device’s identity, the peer’s identity, and the tunnel address before checking Endpoint and AllowedIPs. This guide is for users who already have configuration details from their provider or a self-managed endpoint. It explains how standard WireGuard fields map to Shadowrocket’s setup flow and how to tell apart key errors, blocked UDP traffic, insufficient routing scope, and an unsuitable MTU.

1. Add a WireGuard Server in Add Server

A WireGuard profile in Shadowrocket requires a matching set of parameters. A remote address and port alone are not enough to connect: the PublicKey for your device’s PrivateKey must be registered on the peer, and the tunnel address and allowed address ranges must match the peer configuration. The addresses below are examples only and cannot be used to connect.

Gather Your Parameters

Separate [Interface] and [Peer] in your existing configuration: the former contains your device’s PrivateKey, Address, and other details; the latter contains the peer’s PublicKey, Endpoint, AllowedIPs, and other details. Keep a copy of the original so you can refer back to it.
Choose the Type

Go to Home → tap “+” in the upper-right corner → Add Server → Type, then select WireGuard. Choose the Type before entering parameters; do not enter a WireGuard key in another protocol’s password field.
Map the Fields

Map the Endpoint host and port to Address and Port. Match the Interface PrivateKey and Peer PublicKey to their respective key fields. Enter the tunnel IP in the local-address field, not the remote Address field. Field names and grouping may vary; follow the current app interface.
Save and Test

After saving, return to Home, select the profile, check Global Routing, and turn on the connection. Follow the system prompt to allow the VPN configuration, then test with Connectivity Test and by accessing an actual destination. An enabled switch does not mean the peer handshake succeeded.

Adding a profile manually makes it easier to check each field. If the profile comes from an existing subscription, first check whether refreshing it will overwrite manual changes. Keep a separate copy for troubleshooting and note what you changed. This site does not provide, sell, or recommend nodes or subscriptions; the steps below are only for configurations you already have.

2. PrivateKey and PublicKey: Identify Each Side

WireGuard authenticates devices using key pairs. Your device’s PrivateKey and PublicKey form one pair; the peer has its own pair. In Shadowrocket, Peer PublicKey means the remote peer’s public key, not the public key derived from your current PrivateKey. This is one of the easiest fields to mix up when configuring a profile manually.

Local Interface

PrivateKey: Your device’s private key, used to identify this device. Keep it confidential.
PublicKey: Derived from your device’s PrivateKey; give it to the peer administrator to register.
Address: Your device’s tunnel address, such as 10.66.0.2/32; not the public endpoint.

If you change your device’s PrivateKey, update the PublicKey registered on the peer as well.

Remote Peer

PublicKey: The peer’s public key. Enter it in the client’s Peer PublicKey field.
PresharedKey: An optional additional shared key. If enabled, it must match on both sides.
Endpoint: A reachable peer host and UDP port, such as 192.0.2.10:51820.

The client does not need the peer’s PrivateKey. Never exchange the private keys for the two sides.

A standard WireGuard key is a Base64 representation of 32 bytes of data. It is usually 44 characters long and ends with =. Preserve the final character when pasting; do not add quotation marks, spaces, or line breaks. A plausible length and appearance only indicate that the format may be valid; they do not confirm that the key belongs to the correct peer.

3. Address, Endpoint, and DNS: Keep Them Separate

In a standard configuration file, Address refers to the internal tunnel address. In the Add Server interface, Address usually refers to the remote host. The same English term can mean different things in different contexts, so check which section it appears in. Entering 10.66.0.2/32 as the remote host will not help the client find the public endpoint.

Configuration Value	Example and Meaning	What to Check
Interface Address	`10.66.0.2/32`: the local tunnel IPv4 address.	Enter it in the local-address field based on your source configuration; check the prefix length along with the address.
Peer Endpoint	`192.0.2.10:51820`: the remote host and UDP port.	If the interface has separate Address and Port fields, enter the host and `51820` separately.
IPv6 Endpoint	`[2001:db8::10]:51820`: brackets separate the host from the port in this format.	If the host and port have separate fields, do not enter the combined value in the host field.
DNS	The address or settings for the server responsible for name resolution.	Make sure the DNS resolution path is reachable; DNS does not replace the Endpoint or tunnel address.

192.0.2.10 and 2001:db8::10 are documentation examples. Use the port from your own configuration. 51820 is a common example, not a required WireGuard port. WireGuard uses UDP, so a standard TCP port test—whether it succeeds or fails—cannot prove that the UDP endpoint is reachable.

If the Endpoint uses a hostname, the client must resolve it before sending handshake data. If the hostname itself cannot be resolved, first check DNS resolution on the current network. If the endpoint is reachable but website hostnames fail to resolve, check where DNS requests are actually going. Do not treat both issues as “a key problem.”

4. AllowedIPs and Global Routing: Check Each Separately

In WireGuard’s Peer configuration, AllowedIPs associates address ranges with a peer and checks the source address ranges of received traffic. It is not an app-level domain rule or a list of remote servers you can connect to. For example, 10.66.0.0/24 describes one IPv4 subnet, 0.0.0.0/0 covers all IPv4 addresses, and ::/0 covers all IPv6 addresses.

Access to specific subnets only: If the existing configuration allows only 10.66.0.0/24, do not expect arbitrary public destinations to be reachable through that peer. The remote side must also have the corresponding routes and access permissions.
Cover both IPv4 and IPv6: 0.0.0.0/0 does not include IPv6. For dual-stack access, check ::/0, your local tunnel address, and the peer’s ability to forward IPv6 traffic.
Check how the configuration is mapped: Imported formats may translate AllowedIPs into internal settings. If the manual form has no field with that name, do not enter it into another field at random. Check whether the format is supported and review the saved configuration.
Check app-level routing: Home → Global Routing → Config applies the rules in the current configuration. Requests matched by DIRECT will not automatically use this WireGuard profile just because the AllowedIPs range is expanded.

Shadowrocket’s Global Routing and WireGuard’s Peer address ranges are separate controls. Temporarily choosing Proxy can help isolate rule-related factors, but results still depend on the app’s traffic scope, tunnel parameters, and the peer’s network capabilities. Choosing Direct cannot test the WireGuard forwarding path. Restore your original settings after testing so temporary troubleshooting changes do not become your permanent configuration.

5. MTU and PersistentKeepalive: Adjust Based on Symptoms

MTU sets the maximum packet size inside the tunnel. Encapsulation adds overhead, and the suitable value depends on the underlying network and path. Consider testing MTU only when symptoms point to a packet-size issue, such as small requests working while large pages or transfers stall. If the handshake fails entirely, check the Endpoint, UDP, and keys first.

Keep the Original MTU Setting

Recommended

Start with the value in your existing configuration. If it does not specify one, leave handling to the app defaults. Note the current network, destination, and symptoms for comparison; do not assume a commonly used value is right for every network.

Best for: first-time setup or cases with no evidence of packet-size issues.

Lower the MTU Slightly

If the original value is 1420, keep a copy and try 1380 as a comparison test. This is an example for troubleshooting, not a measured recommendation. Keep the network, destination, and all other parameters the same. If there is no improvement, restore the original value.

Best for: cases where data is exchanged but larger transfers repeatedly stall.

PersistentKeepalive is measured in seconds and periodically sends keepalive packets to help maintain a mapping in NAT or a firewall. 25 is a common example, but use the value that fits your configuration. It is not a reauthentication password or a speed setting, and it cannot fix an incorrect PublicKey or an unreachable port.

Focus on keepalive and network mappings only if communication is difficult to restore after a period of inactivity.
Change only one of MTU or PersistentKeepalive at a time so you can tell which change affected the symptoms.
Record results separately when switching between Wi-Fi and cellular; do not combine results from different underlying networks in one comparison.

6. Match Both Sides: Client and Peer Checklist

A connection switch showing as on at one end does not mean the other end has accepted that identity. Check separately who the client is sending to, which identity the peer allows, and how return traffic finds your device. Avoid reusing the same identity and tunnel address across multiple devices: the peer may update its endpoint mapping between different sources, causing intermittent connectivity.

Checklist: Match the Local Interface with the Remote Peer

Shadowrocket on This Device

The PrivateKey belongs to this device, and its corresponding PublicKey has been registered with the peer.
Peer PublicKey belongs to the intended peer; the Endpoint host and UDP port are correct.
The tunnel address, address ranges, and DNS match the existing configuration.
The correct profile is selected in Home, and Global Routing is set for the test.

Peer Configuration

The corresponding Peer entry has this device’s PublicKey, not the key for another device.
Assign a unique address to this device, such as 10.66.0.2/32, and configure a return route.
The UDP port actually listening matches the port allowed through the firewall.
For access to external networks, the required forwarding, routes, and permissions are in place.

Check that the identities match first, then verify addresses and forwarding. Changing a client field cannot replace the corresponding peer configuration.

7. Common Entry Mistakes and How to Test

Connectivity Test can help assess reachability, but a single latency value does not indicate throughput or handshake status. For each test, record the destination, test method, and underlying network. If you manage the peer, also check its latest handshake time and sent/received counters to confirm whether data arrived. The questions below address observable symptoms without assuming every failure has the same cause.

The profile errors as soon as I save PrivateKey. What should I check first?

Open the profile’s edit screen from Home and check whether you copied the entire PrivateKey = line, quotation marks, or a line break. The field usually needs only the key value after the equals sign. The trailing = is part of the Base64 value and must be kept. Do not try to fix it by adding random characters.

The switch is on, but no data is getting through. Why?

First confirm that the intended profile is selected in Home, then check Global Routing. Next verify the Endpoint, UDP port, and peer PublicKey. If you manage the peer, check its latest handshake and sent/received counters. A running system VPN only confirms that the local tunnel started; it does not prove the peer responded.

I can reach internal addresses, but public websites will not load. What should I check?

Check whether AllowedIPs covers only internal subnets, then check DNS and the peer’s forwarding setup separately. If Global Routing is set to Config, also check which rule matches the destination. Do not assume the peer can forward public traffic just because you changed AllowedIPs to cover all addresses.

It reconnects automatically after I turn it off. Did I enter a field incorrectly?

Go to Settings → On Demand and check the current connection conditions. For manual troubleshooting, pause the relevant automatic triggers, then return to Home and test again. On Demand controls when a connection starts; it is separate from whether the WireGuard keys are correct. Changing keys will not fix an automatic connection trigger.

It works on another device. Can I copy all the settings?

First check whether the peer assigns a separate identity and address to each device. Each device should have its own PrivateKey, with its corresponding PublicKey registered on the peer. Copying the same endpoint details does not mean copying the same identity. Keep separate configurations and compare them on the same network.

At minimum, final verification should confirm three things: the intended profile handles the target request, the required address ranges are reachable, and communication resumes as expected after idle periods. Keep the original configuration and a record of changes. Remove duplicate profiles created during troubleshooting. If you use subscription management, confirm that the next refresh will not overwrite verified settings.