Shadowrocket WireGuard Setup: Private Key, Peer Public Key, and Allowed IPs

In this guide

When setting up WireGuard in Shadowrocket, first distinguish the local Interface from the remote Peer: the local Private Key and tunnel address come from Interface, while the remote Public Key, Endpoint, and Allowed IPs come from Peer. This guide assumes you already have a provider and its configuration details. It explains which section each field belongs to, how to add the configuration, and what to check if the connection fails. The addresses shown illustrate formatting only and cannot be used to connect.

1. Understand the roles of Interface and Peer

WireGuard identifies both ends of a connection with key pairs rather than an account and password. A provider’s configuration usually contains an [Interface] section and a [Peer] section. “Local” means the device using this client configuration; “remote” means the server it connects to. Keep these roles straight when copying values: do not put the local Public Key in the remote public key field.

Identify local and remote fields by section

Interface: local identity

PrivateKey: the local private key. Keep it secret.
Address: the tunnel address assigned to this device. It may include a CIDR prefix length.
MTU: the maximum transmission unit for the tunnel interface. It may be unspecified.
DNS: resolver information from the configuration, not the remote connection address.

Peer: remote identity

PublicKey: the remote public key, used to identify the peer.
Endpoint: the remote hostname or IP address and UDP port.
AllowedIPs: the destination address ranges associated with this Peer.
PresharedKey: an optional preshared key that must match at both ends.

Use the client configuration provided for this device to identify each field. Do not copy values directly from a server-side configuration.

For example, Address = 10.66.0.2/32 in the client configuration is the local IPv4 address used inside the tunnel. Endpoint = 192.0.2.10:51820 is the remote address contacted to establish the connection. Swapping them gives you neither the correct remote endpoint nor the correct tunnel source address.

2. Which Private Key and Public Key should you enter?

In Shadowrocket’s WireGuard editor, Private Key corresponds to PrivateKey under the client’s [Interface] section. The Peer Public Key corresponds to PublicKey under the client’s [Peer] section. The app labels use spaces; configuration keys usually do not. The meaning is the same.

Check the local key

Source: Client configuration’s [Interface] section
Private Key: Copy the entire PrivateKey value
Local Public Key: Derived from the local private key; used to register the device with the remote server
Keep it confidential: Never include the private key in screenshots, chat logs, or public documents

Changing the private key changes the local identity. Update the client public key registered on the remote server as well.

Check the remote key

Source: Client configuration’s [Peer] section
Public Key: Copy the entire PublicKey value for that Peer
Preshared Key: Enter only if explicitly provided in your configuration details
How they relate: The remote public key must match the service at the current Endpoint

A public key and a preshared key are different fields and cannot be used interchangeably.

WireGuard keys are case-sensitive. A common text representation is a 44-character Base64 string, sometimes ending in =. Copy only the value, not a field name such as PrivateKey =, and make sure you include the final character. The expected length only indicates that the format looks plausible; it does not confirm that the key matches the one registered on the server.

3. Match the Endpoint, tunnel address, and MTU

The Endpoint contains both the remote address and UDP port. If the editor has separate fields for the address and port, enter them separately. Do not put an entire “address:port” string in a field that accepts only an address. 51820 is a common example port, not a fixed value for every WireGuard service. Use the value in your own configuration.

Configuration field	Example format	What to enter and check
Endpoint	`192.0.2.10:51820`	When split into separate fields, the address is 192.0.2.10 and the port is 51820. The transport is UDP.
IPv6 Endpoint	`[2001:db8::10]:51820`	Square brackets distinguish the address from the port in a complete Endpoint. In a separate address field, use the format that field accepts.
Address	`10.66.0.2/32`	This is the local tunnel address. If the editor separates the address and prefix length, enter them in the respective fields.
AllowedIPs	`10.66.0.0/24`	The address range associated with this Peer—not a local address or a list of domain names.
MTU	`1420`	Measured in bytes. This is an example value, not a setting that works for every network.
PersistentKeepalive	`25`	Measured in seconds; used to send keepalive packets periodically. Enter it only if the editor provides the corresponding field and your configuration specifies a value.

MTU controls the maximum size of a packet sent through the tunnel. If it is too large, some paths may allow small requests but stall on larger responses. DNS issues, the remote service, or packet loss can cause similar symptoms. Keep the value specified by your provider. If none is specified, leave the app’s default in place; lowering MTU should not be the first step for every connection problem.

If you need to test the MTU, record the original value first. Change only this setting, reconnect, and repeat the test against the same destination.
If the current value is 1420, try 1380 as a modest adjustment. If it does not help, restore the original value instead of continuing to lower it.
Do not enter the configuration’s DNS address as the Endpoint, and do not assume that adding a server automatically applies every DNS setting in the file.

4. Allowed IPs and Shadowrocket routing rules work at different levels

AllowedIPs is used both to select a WireGuard Peer and to validate received addresses. For traffic sent through the tunnel, it determines which Peer handles a destination address. For received, decrypted traffic, it checks whether the source address falls within that Peer’s allowed range. It describes IP networks only; domains such as example.com are not accepted.

0.0.0.0/0 covers all IPv4 addresses, and ::/0 covers all IPv6 addresses. This does not force Shadowrocket to send all app traffic through this server. Global Routing and the rules in Config determine where traffic goes first. When traffic is routed to WireGuard, the Peer’s Allowed IPs must also cover the destination address.

Config: follow rules

Recommended

Use the policies selected by the current Config rules. Before returning to your usual configuration, confirm that the rule for the traffic you’re testing points to the expected server or policy group, and check the FINAL fallback.

Best for: setups with rules already in place that need to distinguish direct traffic from proxy traffic.

Proxy: temporarily isolate rule behavior

Use the proxy for all traffic within the applicable proxy routing scope to reduce interference from Config rules during testing. This cannot fix an incorrect key or extend the networks the remote server can actually reach.

Best for: temporarily checking whether a rule miss is causing traffic to go direct after you have verified the server settings.

Direct: bypass the tunnel

Traffic uses the direct route. Opening a public website in this mode does not prove the WireGuard server is configured correctly or that a private network on the remote side is reachable.

Best for: checking whether your local network can reach the same public test destination.

If your provider allows access only to 10.66.0.0/24, do not change Allowed IPs to cover all IPv4 and IPv6 addresses just to test a public website. Even if the app accepts the change, the remote side may not provide public traffic forwarding, IPv6 routing, or the required access permissions. Test against a destination your configuration explicitly allows.

5. Add and test WireGuard from Home

Keep a copy of the original configuration and note the current Global Routing setting before you start. A server entry in Home, a rule file in Config, and app preferences in Settings are separate things: adding a server does not select a rule file. The steps below use manual entry; available fields may vary, so follow what the app actually displays.

Review your configuration

Make sure the client configuration includes the Interface private key and address, along with the Peer public key, Endpoint, and Allowed IPs. If it includes a Preshared Key or MTU, record those too so you don’t copy only part of the configuration.
Choose the protocol

Go to Home → tap “+” in the top-right corner → Type → WireGuard. Check the Type first so you don’t enter a WireGuard public key in the Password field for another protocol.
Enter the fields

Fill in the local and remote fields separately. Match the Endpoint address and port to the corresponding fields in the editor, then verify the Private Key, Peer Public Key, tunnel address, and any available additional fields.
Save and select

Save, return to Home, and tap the server you just added. Confirm that the selection indicator appears on the left. If your current rules use a policy group, check which server the group actually selected; the default selection in Home may not be the one in use.
Test the connection

Turn on the connection switch in Home. The first time, follow the system prompt to allow the VPN configuration to be added. Use Connectivity Test to check whether the test destination is reachable, then try an address your provider explicitly allows.
Restore your settings

If you temporarily changed Global Routing while troubleshooting, restore the original setting after testing. Go to Settings → On Demand and check the on-demand connection settings. During troubleshooting, prevent them from triggering automatic connections or disconnections that could interfere with manual tests.

6. Troubleshooting: check identity, route, and destination

Why does the connection still time out when both keys are entered?

First, confirm that the Public Key comes from the Peer section of the client configuration, not from the local device. Then check the Endpoint address, UDP port, and Preshared Key. WireGuard does not necessarily return a “wrong password” message as an account login would. A timeout may also mean that the UDP route is blocked, so it alone does not prove that a key is wrong.

Why does it stop working when I switch Wi-Fi networks?

Keep the server, destination, and Global Routing setting the same while testing Wi-Fi and cellular networks separately. Avoid changing several variables at once. If only one network fails, first check UDP reachability, Endpoint hostname resolution, and path MTU on that network. Then check whether Settings → On Demand has a different action configured for it.

An IP address works, but the domain doesn’t. What should I check?

First confirm that both requests reach the same service. Then check the DNS settings and domain rules in the current Config. An IP address and a domain name may match different rules, or produce different results because the TLS certificate name differs. Don’t replace the Peer public key or remote port based on this alone.

Can I use the same configuration on both my iPhone and iPad?

Whether multiple devices can use the same configuration depends on the service you already have. If both devices use the same private key and tunnel address at the same time, the remote server may see the communication endpoint change repeatedly, interrupting one device when the other reconnects. If both need to be online at once, ask your provider whether it can assign a separate identity and tunnel address to each device.

Why do some websites still go direct when Allowed IPs covers all addresses?

Return to Home and check Global Routing, then go to Config and review the active file’s DOMAIN-SUFFIX, IP-CIDR, and FINAL rules and their policies. Allowed IPs does not override app-level routing. If a rule sends the destination to DIRECT, it won’t use this WireGuard route.

7. Final checks and handling sensitive information

After completing a repeatable test, keep a record matching the original configuration to the values you ended up using. Recheck the active server entry after manual edits, reimporting, or updating an existing subscription; do not assume local changes will persist through future updates. For changes to server addresses or keys, use the latest configuration provided by your provider.

Identity matches: The local Private Key pairs with the client public key registered on the remote server, and the Peer Public Key belongs to the current remote service.
Addresses are clear: Endpoint is the remote entry point, Address is the local tunnel address, and Allowed IPs lists the IP networks associated with the Peer.
Route is verifiable: Record the network used for testing, Global Routing setting, selected server, and destination. Change only one variable at a time.
Keep a way back: Record the original value before changing MTU, rules, or routing. If the test fails, restore it instead of stacking multiple trial-and-error changes.
Remove sensitive data: Before asking for help, remove the Private Key, Preshared Key, and credentials in any existing subscription link. Check configuration files for the same information before sharing them.

Shadowrocket is a paid client for Apple platforms, used primarily on iPhone and iPad. The App Store is the only place to get it, and its developer is Shadow Launch Technology Limited. The app is a one-time purchase; buying the app does not include a network service plan. Check the App Store listing for system requirements and purchase availability. This guide explains how to enter and verify an existing configuration; it does not change the network access provided by your service.