Shadowrocket WireGuard Setup: PrivateKey, PublicKey, Endpoint, and MTU Explained

1. Local and Remote Settings in a WireGuard Configuration

In Shadowrocket, WireGuard is a connection protocol—not a subscription format or a set of routing rules. Using the client configuration from your provider as a reference, [Interface] describes the local tunnel interface, while [Peer] describes the remote peer. First confirm that the file is intended for a client, then enter its fields. A server configuration cannot be used as a client configuration.

Get subscription links and standalone configurations from your provider. If importing a subscription has already created a complete WireGuard entry, verify that entry rather than creating a duplicate with the same name. Subscription updates may overwrite parameters. If you need to test changes, keep the original entry and use a separate test copy instead of modifying the subscription-managed entry.

Entering the configuration correctly and routing requests through that connection are separate issues. The selected entry in Home, the Global Routing mode, and the rules matched in Config all affect the request path. Verify the connection parameters first, then check whether traffic is assigned to that entry. This helps avoid mistaking a rule that sends traffic direct for a WireGuard failure.

2. How PrivateKey, PublicKey, and PresharedKey Relate

PrivateKey is the private part of the local identity. In a client configuration, the PublicKey under [Peer] identifies the remote peer. These belong to different identities and cannot be swapped. Don’t enter the public key derived from the local PrivateKey as the remote PublicKey. The server must register the public key associated with the local PrivateKey for the two configurations to match.

WireGuard keys are 32-byte values encoded in Base64. They’re commonly 44 characters long and may end with =. A matching length only checks the format; it doesn’t prove that the key matches the server. When copying, remove leading and trailing whitespace and avoid including line breaks, quotation marks, or explanatory text. Don’t remove the trailing padding character.

3. Endpoint and Address: Server Entry Point vs. Tunnel Address

Endpoint contains the remote host and port. For example, in 192.0.2.1:51820, the host is 192.0.2.1 and the port is 51820. If Shadowrocket’s editor has separate fields for the address and Port, enter them separately. Don’t paste the full host-and-port string into a field that accepts only a hostname. An IPv6 Endpoint uses square brackets when combined with a port, as in [2001:db8::1]:51820.

Address is the local address used inside the tunnel, usually provided with a prefix length, such as 10.66.0.2/32. If your provider supplies both IPv4 and IPv6 addresses, enter the assigned values as provided. Don’t put the public Endpoint address in Address, and don’t copy the same tunnel identity from another device and use both at once—this can cause identity or address conflicts.

The addresses in the table illustrate the fields; they aren’t usable configuration values. In particular, 192.0.2.1 and 2001:db8::1 are documentation-only example addresses. A working connection also requires an open port, remote UDP support, matching keys, and a local network that allows the required traffic.

4. Check WireGuard Entries Added from Home

Manual setup is for configurations where you already have the individual parameters. The steps below use the English interface labels; field order may vary by device layout. If a parameter from your provider has no corresponding field in the editor, don’t force it into another field. First confirm how to import the configuration and which fields are supported.

1. Keep the Original Configuration

   Save the original parameters from your provider, and note the entry selected in Home and the current Global Routing mode. Change one setting at a time during testing so you can revert it easily.

2. Select the Protocol

   Go to Home → tap “+” in the upper-right corner → Type → WireGuard. Confirm the Type before entering the address, Port, and keys so you don’t carry over assumptions from another protocol’s form.

3. Map the Fields

   Split Endpoint into the remote host and Port. Enter the local private key as PrivateKey and the remote public key as PublicKey. Fill in Address, DNS, and MTU according to the original configuration and the fields supported by the editor.

4. Save and Select

   After saving, return to Home, select the new entry, and turn on the connection. The first time you configure a VPN, follow the system prompts to authorize it. A VPN Connected status from the system doesn’t necessarily mean the remote handshake succeeded or that requests are working.

5. Keep Test Conditions Consistent

   Start with the same network and test request. If Settings → On Demand is enabled, note its conditions so automatic connection behavior doesn’t interfere with manual testing. Restore the original settings when you’re done.

Don’t assume all services are working just because a latency test in Home returns a value once. Results depend on the test method, target, and request path. Also check DNS resolution, whether the intended page loads, and whether larger content transfers successfully. Conversely, a failed latency test alone doesn’t prove that the PrivateKey is wrong.

5. DNS and AllowedIPs: Resolution Path vs. Request Path

DNS isn’t part of the WireGuard encrypted handshake. It’s a setting commonly used by configuration tools to specify resolvers. Shadowrocket’s actual DNS behavior also depends on the active Config and related DNS settings. Check the DNS address in your provider’s configuration alongside the app’s existing resolver settings; don’t look at just one of them.

If the Endpoint is a hostname, it must be resolved before the tunnel can come up. If the only available resolver is reachable only through the tunnel that hasn’t been established yet, this can create a dependency loop. Ask your provider how to resolve the entry-point hostname in this case; don’t change DNS to an address whose reachability you can’t confirm.

• Check entry-point resolution first: If the Endpoint is a domain name, confirm that your current network can resolve it. Check again if the address changes.
• Then check DNS for your traffic: Once the tunnel is up, confirm that DNS queries for the destination domain get a valid response. Testing a numeric IP alone isn’t enough.
• Keep the two rule layers separate: AllowedIPs belongs to the WireGuard peer configuration. DOMAIN-SUFFIX, IP-CIDR, and FINAL are Shadowrocket traffic-routing rules.
• Check the actual route: When Global Routing uses Config, whether requests go through the selected WireGuard entry depends on the rules and policies. Check the active Config, not just a file that isn’t enabled.

6. Choosing an MTU: Keep the Original Value and Change One Setting at a Time

MTU is the maximum size, in bytes, of an IP packet an interface can carry. WireGuard adds transport encapsulation around the original packet, so the tunnel MTU is usually smaller than the underlying link MTU. Configurations commonly use 1420, but it isn’t a universal setting. The underlying link, additional encapsulation, and path constraints can all affect the right value.

A typical troubleshooting clue is that small requests work but larger responses stall, or that large transfers fail after switching networks with the same configuration. This may involve path MTU discovery or fragmentation, but packet loss or congestion can cause similar symptoms. Verify the keys, Endpoint, and DNS first, then narrow it down with a comparison that changes only the MTU.

A smaller MTU doesn’t mean faster performance. It may prevent large-packet issues on some paths, but it also increases the number of packets and encapsulation overhead needed to send the same amount of data. Draw conclusions by comparing results on the same network, entry, and destination—not by comparing latency-test numbers alone.

7. Troubleshooting Connection Failures: Check in Layers

First distinguish between three states: the system VPN is running, the remote peer is reachable, and the target request completes. WireGuard can remain quiet when there’s no traffic, so a short period with no data doesn’t necessarily mean the connection is down. Repeatedly turning the connection off and on won’t fix an incorrect PublicKey or port.

If the device frequently switches between Wi-Fi and cellular, record the results on each network separately. The optional PersistentKeepalive sends periodic keepalive packets; 25 seconds is a common example. Set it only if your provider recommends it or you need to maintain a NAT mapping, and only if your configuration method supports it. It won’t fix an incorrect key or make the connection faster.

When reporting a problem to your provider, note the network type, Endpoint port, type of request affected, whether only large transfers fail, and how results differ before and after changing the MTU. Before sharing configuration screenshots or logs, redact the PrivateKey, PresharedKey, subscription tokens, and other identifying information. Reproducible details are more useful for troubleshooting than simply saying “it won’t connect.”

• Make sure the parameters all come from the same client configuration, rather than mixing keys and addresses from different devices.
• Use the same selected entry for every test and note the current Global Routing mode.
• Revert changes that didn’t help. Otherwise, multiple variables may make the cause impossible to identify.