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

Read the configuration first: Interface is local, Peer is remote

A WireGuard configuration usually has two sections: [Interface] and [Peer]. The first describes this device, including its Private Key, tunnel Address, and sometimes DNS and MTU. The second describes the remote peer, including its Public Key, Endpoint, Allowed IPs, and optional Persistent Keepalive. Shadowrocket may arrange the fields differently from the text configuration, but never swap keys between the two sections.

On Shadowrocket’s Home screen, tap “+” in the upper-right corner, select WireGuard under Type, then fill in the fields using your existing configuration. If you have a complete configuration file, first identify which section each line belongs to. Don’t guess missing values from a screenshot of the settings. Field names and grouping may vary by screen; follow the current app interface.

The text below shows which section each field belongs to. The example keys are not valid credentials, and example.com is not a reachable service address. Use the exact values from your existing configuration.

[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
Address = 10.66.0.2/32
DNS = 10.66.0.1

[Peer]
PublicKey = BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=
Endpoint = wg.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Fill in Interface: Private Key, Address, and DNS

Private Key is the private key for this device. Copy the complete value from the PrivateKey line in your existing configuration. It is not the Peer’s PublicKey or an account password. Check for leading or trailing spaces, line breaks, and missing characters. Never post your private key in a public discussion or troubleshooting screenshot. If your configuration doesn’t include a private key, check with the provider of the original configuration instead of substituting an example value.

Address is the address assigned to this device inside the tunnel, usually shown with its prefix length, such as 10.66.0.2/32. The /32 is part of the address configuration, not an Endpoint port. If your configuration also lists an IPv6 address, check and enter it in the format provided. Don’t enter the server address as the local Address.

1. Open the editor

   On Home, tap “+” in the upper-right corner → Type → WireGuard to find the fields for local and Peer settings. To check an existing entry, open its edit screen.

2. Check the local settings

   Map PrivateKey under [Interface] to Private Key, and Address to the local address field. Keep the prefix length shown in your configuration.

3. Check the Peer settings

   Map PublicKey, Endpoint, and AllowedIPs under [Peer] to their corresponding fields. Before saving, double-check which key belongs where.

4. Test after saving

   Return to Home, select the entry you just saved, and connect. First check whether the connection can be established, then test the destination. Don’t keep changing MTU before verifying the keys and Endpoint.

DNS specifies the address used for name resolution through the tunnel; it is not the local Address. If your configuration lists DNS = 10.66.0.1, first confirm that this address is part of your existing service configuration, then check that Shadowrocket’s DNS settings match. If you can reach the peer but only by IP address, and domain names don’t resolve, DNS is one setting to investigate. That symptom alone doesn’t prove the key is wrong.

Fill in Peer: Public Key, Endpoint, and keepalive

Public Key is the remote peer’s public key, supplied in your existing configuration. Keep it separate from the local Private Key and enter each in the correct field. If the key is incorrect, the expected WireGuard handshake won’t complete even if the Endpoint is reachable. If your configuration also includes PresharedKey, check for a corresponding Pre-shared Key field and enter the exact value. Don’t create one if none was provided.

Endpoint consists of a hostname or IP address and a port, for example, wg.example.com:51820. Here, 51820 is only a format example; use the port in your existing configuration. Keep the colon when copying, and don’t mistake the tunnel IP in Address for the Endpoint. If the Endpoint uses a domain name, that name must resolve before connecting. A DNS resolution failure and an unreachable port are different issues to troubleshoot.

WireGuard uses keys to identify the peer and an Endpoint to specify where to send data. So, being able to save an entry only means the fields were accepted; it doesn’t mean the peer completed a handshake. Troubleshoot configuration saving, connection establishment, and access to the destination separately. Don’t assume one setting is responsible for every failure.

Allowed IPs: choose which destination addresses go to the Peer

Allowed IPs is neither a subscription address nor a server access list. In the local configuration, it defines which destination addresses should be routed to that Peer. 0.0.0.0/0 covers all IPv4 addresses, while ::/0 covers all IPv6 addresses. Using both means the Peer receives traffic for both address families. If your configuration lists only specific subnets, don’t change them to /0 just for convenience.

For example, 10.66.0.0/24 matches only that IPv4 subnet. If you need to reach this subnet while handling other addresses as before, this differs from a route that covers all addresses. A shorter prefix generally matches a larger address range; /32 matches just one IPv4 address. Distinguish the local Address = 10.66.0.2/32 from the Peer’s AllowedIPs = 10.66.0.0/24: the values look similar, but they serve different purposes.

Also distinguish WireGuard’s Allowed IPs from Shadowrocket’s Global Routing. Allowed IPs defines the address range routed to a particular Peer; Global Routing controls how the app handles requests. Modes such as Proxy, Direct, and Config affect test results. If the current mode is Direct, whether a webpage loads doesn’t tell you whether the new WireGuard entry handled the request. In Config mode, also check which rule matched and which policy was selected.

Setting MTU: start with the configured value, then troubleshoot based on symptoms

MTU limits the size of an individual packet in the tunnel. WireGuard encapsulation uses some of the available transmission space, and path limits vary by network, so there’s no single value that works for every connection. If your existing configuration specifies an MTU, use that value first. If not, keep Shadowrocket’s current default and don’t override it with a guess before the connection is established.

If the handshake and basic access work, but some pages take a long time to load or larger transfers stall, MTU may be worth investigating. The same symptoms can also result from DNS, the destination service, or network changes. A better order is to verify the keys and Endpoint first, check Allowed IPs and Global Routing next, and only then adjust MTU based on the original configuration provider’s guidance. Keep a record of the original setting, and retest on the same network and destination.

The network path may change when you switch from Wi-Fi to cellular. A successful test on one network doesn’t prove the setting will work the same way on every network. Settings → On Demand controls connection behavior based on network conditions and is a separate set of settings. When troubleshooting the parameters themselves, manually select the same WireGuard configuration on a known network to avoid mistaking an automatic connection change for an MTU problem.

Troubleshooting after connecting: check each stage where the issue occurs

First confirm that you’re using the entry you just edited. Then note whether the problem occurs while establishing a connection, reaching a specific subnet after connecting, or resolving a domain or loading content. Each symptom points to different checks. Changing the keys, DNS, Allowed IPs, and MTU all at once after saving makes the results difficult to compare.

Keys and addresses in a WireGuard configuration must match the service details you already have. Shadowrocket is a paid client available on Apple platforms. iPhone and iPad users should get it through the App Store; verify the developer details on the store page. Check the App Store listing for system requirements. Buying the app and obtaining WireGuard connection details are separate things; purchasing the app does not generate connection settings from a service provider.