Shadowrocket WireGuard Setup: PrivateKey, Peer, AllowedIPs & MTU

At a glance

This guide is for users who already have a WireGuard configuration from their provider and need to check its settings in Shadowrocket. First, distinguish the local interface from the remote Peer, then verify the address, keys, AllowedIPs, DNS, and MTU. To troubleshoot, change one setting at a time. The addresses and ports shown here illustrate how fields relate; they are not working connection details.

1. Understand the roles of Interface and Peer

WireGuard configurations typically use [Interface] for the local tunnel interface and [Peer] for a remote endpoint allowed to communicate. Shadowrocket may present these as separate fields, so don’t map them based only on their order in the file—and never swap the keys between the two sections.

The local PrivateKey identifies this device. The remote side must register the corresponding local public key. The Peer PublicKey in the local configuration verifies the remote side’s identity. Both are usually Base64 strings; their length or trailing characters alone won’t tell you which field they belong in.

Which settings belong to the local interface or remote Peer

Interface: Local identity

PrivateKey: The local private key. Keep it secret.
Address: The tunnel address assigned to this device.
MTU: The maximum packet size for the tunnel interface.
DNS: A resolver setting that may be included in the configuration; it is not a WireGuard handshake parameter.

Peer: Remote identity and route

PublicKey: The remote public key, not the local one.
PresharedKey: An optional pre-shared key that must match on both sides.
Endpoint: The remote public address and UDP port.
AllowedIPs: The destination and source address ranges associated with this Peer.

Check which side each setting belongs to before mapping fields. If you change the local private key, the remote side must also update the registered local public key.

2. Check addresses, keys, and ports field by field

Address is the internal tunnel address, not the remote server address. For example, 10.66.0.2/32 represents a single IPv4 host address; /32 is the prefix length and should not be changed to /24 arbitrarily. If the app separates the address and prefix into different fields, enter them separately rather than pasting the entire line.

Source field	What to enter	Common mistakes and how to check
`PrivateKey`	The local WireGuard private key.	Don’t enter the remote PublicKey. When copying, check for line breaks, spaces, or missing characters.
`Address`	The IPv4 or IPv6 tunnel address assigned to this device.	Don’t enter the Endpoint. Keep the original prefix length and check IPv4 and IPv6 settings separately.
Peer `PublicKey`	The remote Peer’s public key.	Don’t substitute the local public key; this must match the remote endpoint you’re connecting to.
`PresharedKey`	An optional key shared by both sides.	Don’t make one up if it isn’t in the original configuration. A mismatch—or a key present on only one side—will prevent communication.
`Endpoint`	The remote address and UDP port.	In `192.0.2.10:51820`, enter the address and port in their respective fields. This address is for illustration only.
`PersistentKeepalive`	The interval, in seconds, for sending keepalives to maintain a NAT mapping while idle.	`25` is a common example, not a universal requirement or a connection timeout.

WireGuard uses UDP. Port 51820 is a common example, not a protocol requirement—and using it doesn’t make an arbitrary address reachable. For an IPv6 Endpoint, a configuration file typically uses the form [2001:db8::10]:51820. If the app separates the address and port, follow the input format for those fields when handling the brackets and colon.

UDP

WireGuard’s outer transport; a reachable TCP port doesn’t mean the tunnel is working

51820

Common Endpoint port example; use the value in your existing configuration

25 seconds

Example PersistentKeepalive interval, not a default requirement

3. Add the configuration from Home and run a repeatable test

Save a copy of the original configuration before making changes. Note whether you’re using Wi-Fi or cellular and the current Global Routing setting. If the configuration comes from an existing subscription, first confirm it includes a WireGuard entry. Updates may recreate entries, so record any differences before editing to avoid mistaking a later overwrite for an unsaved change.

Gather the original configuration

Confirm it includes the local PrivateKey, tunnel Address, remote PublicKey, and Endpoint. If you only have a public key or a port, ask the original configuration provider for details; these alone aren’t enough to derive a complete set of connection settings.
Select the protocol

Go to Home → + → Type → WireGuard. Enter the remote address, port, local key, and tunnel address in the fields shown. Some screens split the address and prefix; don’t paste the entire configuration file into a single key field.
Check the remote settings

Enter the Peer PublicKey and check the PresharedKey, AllowedIPs, and keepalive interval in your existing configuration. If the current screen doesn’t have a corresponding field, don’t put the value in another field just because its name looks similar. First confirm which settings that import method supports.
Save and connect

After saving, return to Home, select the entry you just added, and turn on the connection switch. The first time you connect, allow the VPN configuration when prompted by the system. Seeing the VPN status only confirms that the tunnel interface has started; it doesn’t prove that the remote endpoint has responded.
Record the test results

For a brief comparison, go to Home → Global Routing → Proxy and check that the selected entry can carry the request you’re testing. Record the test destination, symptoms, and network type. Then restore your usual Config or other setup rather than leaving the test setting in place.

During testing, check Settings → On Demand for any automatic connection conditions. On Demand controls when the system starts a connection; it doesn’t decide which rule a domain follows. If it reconnects after a network change, note that in your test results so you don’t mistake an automatic reconnection for the effect of a WireGuard setting change.

4. AllowedIPs and Global Routing operate at different levels

WireGuard’s AllowedIPs associates IP ranges with a Peer: for outgoing traffic, it selects the Peer that can carry traffic to the destination; for incoming traffic, it restricts which internal source addresses that Peer can use. It doesn’t accept domains and isn’t the same as Shadowrocket’s DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL.

0.0.0.0/0 covers all IPv4 addresses, but not IPv6.
::/0 covers all IPv6 addresses; entering it doesn’t mean the remote endpoint provides a working IPv6 route.
10.66.0.0/24 covers only the specified private subnet, not all Internet destinations.
If your import or editing method exposes AllowedIPs, preserve its original purpose. Don’t widen the ranges blindly just to make every website load.

In Shadowrocket, also check whether the request is actually routed through the WireGuard entry. Under Config, the active configuration’s rules and policies determine how requests are handled; don’t assume traffic that misses a rule will always go direct. The fallback setting determines the final route. Even with broad AllowedIPs, a request matching DIRECT won’t automatically use the selected WireGuard path.

Config: Routing based on the configuration

Recommended

Handle requests according to the rules and policies in the active configuration. Check whether the destination matches the intended rule and whether its policy actually selects the WireGuard entry. Also check the fallback direction for FINAL.

Use when: The tunnel is confirmed to work and you’re restoring your usual rule-based routing.

Proxy: Compare the proxy route

Use briefly to check the selected proxy route while reducing interference from rule selection. This mode won’t fix an incorrect key, an unreachable UDP Endpoint, or a missing route on the remote side.

Use when: You need to tell whether traffic isn’t reaching the entry because of routing, or the entry itself isn’t working.

Direct: Direct-connection baseline

Use the direct route as a network baseline and observe how the same destination behaves without a proxy route. A website working under Direct doesn’t prove the WireGuard settings are correct.

Use when: Checking whether your local network can reach the test destination at all.

5. Check DNS and MTU if the connection is still misbehaving

DNS determines how hostnames are resolved

The DNS field in a WireGuard configuration isn’t needed for the handshake. However, if the Endpoint is a hostname, it must be resolved before the outer connection can be established. Website hostnames also need to be resolved after the tunnel is up. Record failures to resolve the Endpoint separately from failures to resolve a destination hostname; neither alone points to an incorrect key.

DNS in a configuration file is usually an extension provided by the client configuration tool, not a parameter exchanged by the WireGuard protocol itself. After importing, check the DNS settings in the active Config and confirm which route DNS requests actually use. Don’t assume the DNS value in the original file overrides Shadowrocket’s existing settings.

If the DNS address is private and reachable only through the tunnel, first confirm that the tunnel route and remote access permissions work. Using it before the connection is established can create a dependency problem.
If only certain domains fail, note whether queries time out, return no results, or resolve to an unexpected address. Then check the DNS settings and matching rules.
Don’t draw conclusions just because accessing an IP address works. HTTPS also depends on the hostname, certificate, and SNI, so a page opened by IP may not be the same service as the one opened by domain.

MTU sets the maximum size of packets inside the tunnel

When MTU is too large, the connection may appear to come up and small amounts of text may load, while large pages, uploads, or other large transfers stall. This is a clue, not a definitive diagnosis; remote congestion, UDP packet loss, or server-side limits can cause similar symptoms. An MTU that’s too small can increase the number of packets and encapsulation overhead, so smaller isn’t always more reliable.

Keep the MTU supplied by your configuration provider initially. Record results using the same network, destination, and action.
If the original value is 1420, try 1380 as a lower-value comparison. These figures are test examples, not the best settings for every network.
After saving, disconnect and reconnect, then repeat the same test. Don’t change DNS, the Endpoint, or keys during this test.
If there’s no improvement, restore the original value and continue checking for packet loss along the route and the remote endpoint’s status. For IPv6 tunnels, don’t arbitrarily set the MTU below the minimum link MTU of 1280.

6. Troubleshoot based on symptoms, not a single latency test

A latency test reports results for a particular test method; it doesn’t guarantee that application traffic is working. Troubleshoot in order: outer UDP reachability, Peer identity matching, tunnel address and remote routing, DNS, then application requests. If you can check the remote handshake and traffic counters, compare them with a request you deliberately initiated rather than relying only on a connection icon in the interface.

The VPN icon is showing. Why won’t webpages load?

Return to Home and confirm the intended WireGuard entry is selected, then briefly switch to Global Routing → Proxy for comparison. If it still fails, first check the Endpoint, UDP port, and how the public keys match on both sides. If the interface starts but there’s no response from the remote side, changing DNS or MTU is unlikely to help.

It stops working on cellular. Should I change the PrivateKey?

Don’t change the identity yet. Keep the original settings and record the results on Wi-Fi and cellular separately. Check whether the Endpoint resolves and whether UDP is reachable on each network. If it only fails after being idle, ask the original configuration provider whether PersistentKeepalive is needed. Changing the private key requires the remote side to register the new public key.

Small pages load, but file uploads stall. What should I do?

Keep the network and test destination the same, lower only the MTU, then reconnect and test again. If nothing changes, restore the original MTU. Continue checking for packet loss, remote routing, and destination service limits; don’t assume every large-transfer failure is an MTU issue.

Can I use the same configuration on an iPhone and an iPad?

That depends on how the remote side assigns configurations. Using the same private key and tunnel address on two devices at once can cause the remote endpoint to see its Endpoint change back and forth. For simultaneous use, ask the original configuration provider about separate Peers, keys, and addresses instead of simply copying the same entry.

My MTU reverted after I updated the subscription. Why?

Compare your notes from before and after the update to see whether the subscription recreated the entry. Follow the update process for parameters managed by the subscription. If you need to test a setting separately, keep the original entry and note the purpose of your local copy so it isn’t confused with the automatically updated entry.

7. Keep troubleshooting notes and understand the limits

A useful troubleshooting record lets you reproduce the issue under the same conditions without exposing connection credentials. Keeping the original working settings is more valuable than making several unrelated changes in a row. When you’re done, restore your usual Global Routing selection and check that On Demand still behaves as expected.

Record the environment: iPhone or iPad, Wi-Fi or cellular, test destination, and the specific action that failed.
Record the route: selected entry, Global Routing mode, and the matching rule or policy in Config.
Record the changes: note one difference at a time, such as “MTU changed from 1420 to 1380.” Don’t disclose the PrivateKey or PresharedKey.
Record the results: distinguish between resolution failures, connection timeouts, partial page issues, and stalled large transfers. Note what happens after restoring the original value.