When setting up WireGuard, distinguish your device’s identity, the peer’s identity, and the outer connection address before checking the tunnel’s Address. This guide is for users who already have a configuration from their provider. Match each value to the right field, establish a baseline with the default MTU, then test DNS, UDP reachability, and recovery after idle periods separately. This helps avoid blaming every connection issue on the keys or MTU.
Distinguish keys, tunnel addresses, and Endpoint
Selecting WireGuard as the type in Shadowrocket does not by itself establish a working connection. WireGuard uses keys to identify both peers and UDP to carry encapsulated data. The server must also have the client’s PublicKey registered and allow the assigned tunnel address. Completing the client-side fields alone cannot replace the server-side peer configuration.
This guide explains standard WireGuard fields from [Interface] and [Peer]. These are names used in configuration files; Shadowrocket’s editing screen may use different groupings or labels. Match values to the fields shown in the app, and don’t assume an Address field refers to the server’s address rather than an address inside the tunnel.
For example, 192.0.2.10:51820 illustrates the “hostname or IP plus port” format for an Endpoint, while 10.66.0.2/32 illustrates an IPv4 address inside the tunnel. The first uses a documentation example address. Neither is a connection setting provided by this guide; use values from your existing configuration. Port 51820 is a common example, not a fixed port for every WireGuard service.
Where to get PrivateKey and PublicKey values
PrivateKey is the private key for this client’s identity. The corresponding client PublicKey must be registered on the server. The PublicKey in the client’s [Peer] section is the server’s public key. These two directions are easy to mix up: entering your own public key as the peer’s key won’t authenticate as intended, even if the format is valid.
Local identity and address
- PrivateKey
- Private key from the current client configuration; keep it secret.
- Client PublicKey
- Derived from the local PrivateKey and provided to the server for registration.
- Address
- Address inside the tunnel assigned by the server, such as 10.66.0.2/32.
The local private key, client public key registered on the server, and assigned address must correspond.
Peer connection details
- PublicKey
- The peer server’s public key, not the client’s own public key.
- Endpoint
- Server hostname or IP address, plus the actual UDP port.
- PresharedKey
- Optional preshared key; enter it only if the original configuration requires one.
Don’t substitute PrivateKey or PublicKey for PresharedKey, or make up a value.
A common Base64-encoded WireGuard key is 44 characters and usually ends with =. This is only a format check, not proof that the key belongs to the right peer. When copying, check for extra spaces, line breaks, or quotation marks; don’t add or remove characters to force a particular length. If a key is exposed, replace it and update the server’s registration rather than just changing the node’s remark.
Steps to check a WireGuard entry in Home
Keep your current working configuration, then add a separate entry for testing. The steps below focus on manual entry. If you imported parameters from an existing subscription, first confirm that the resulting entry is actually WireGuard. Don’t paste WireGuard configuration text into a field that accepts only a subscription URL, and don’t assume every format is recognized through the same import option.
-
Choose the type
Go to Home → “+” in the top-right corner → Type → WireGuard. Confirm the type before entering values to avoid using similarly named fields in an editor for another protocol.
-
Enter peer details
Enter the hostname and port from the original Endpoint in the server address and port fields. For example, 192.0.2.10:51820 means the host is 192.0.2.10 and the UDP port is 51820. This only demonstrates how to split the value.
-
Match the identities
Enter the local PrivateKey, the peer’s PublicKey, and the PresharedKey if the original configuration requires one. Check the source of each value and don’t swap the client and server public keys.
-
Check the address
Enter the assigned Address inside the tunnel in the local address field. If the original configuration includes both IPv4 and IPv6 addresses, check each one. If the app separates the address and prefix, enter them in the corresponding fields.
-
Save and verify
After saving, return to Home, select the entry, and check Global Routing. On the first connection, follow the system prompts to authorize the VPN configuration, then verify it with an actual request rather than relying only on the connection toggle.
Entries managed by a subscription may be overwritten from the source configuration the next time it updates. Before testing MTU or keepalive settings, record the original values and use a test entry that can be kept independently. If your changes disappear, first check whether the subscription updated instead of repeatedly re-entering keys. In Shadowrocket, Home, Config, and Settings handle connection selection, configuration management, and app settings respectively. Editing a node does not automatically change the currently selected Config.
How Address, AllowedIPs, and routing rules differ
Address is the local address of the tunnel interface, not a DNS address or the server’s public IP. The suffix /32 represents a single IPv4 host address, and /128 a single IPv6 host address. Don’t change an address assigned by your provider to one used by another device. Reusing the same identity or address can change where return traffic goes and cause intermittent interruptions.
| Setting | What it means | What it does not tell you |
|---|---|---|
| Address | Local tunnel address, for example 10.66.0.2/32 | It cannot be used as a public server address |
| Endpoint | The host and port that carry outer UDP packets | An open port does not mean peer authentication succeeded |
| AllowedIPs | Peer address selection and incoming-source restrictions in standard WireGuard | It is not the same as Shadowrocket’s domain-based routing rules |
| Global Routing | Shadowrocket’s current global routing mode | Selecting a WireGuard entry does not mean every request uses it |
In standard WireGuard configurations, 0.0.0.0/0 and ::/0 cover all IPv4 and IPv6 address ranges respectively. But when you use WireGuard as a Shadowrocket node, whether a request goes through that node also depends on Global Routing, the active Config, and the policy it matches. Don’t assume that every app request will use the node just because these ranges appear in the original file.
DOMAIN-SUFFIXmatches domain suffixes; it does not validate WireGuard keys.IP-CIDRmatches destination IP ranges; it does not assign an Address to the local interface.GEOIPmatches based on an IP address’s geographic allocation; it won’t fix an unreachable UDP Endpoint.FINALis the fallback rule when no preceding rule matches; its policy is not necessarily the currently selected WireGuard node.
MTU: keep a baseline before investigating large-packet issues
MTU is the largest IP packet size a tunnel interface can carry, not a speed limit. WireGuard encapsulation adds overhead for the outer IP, UDP, and protocol headers. If the underlying path supports smaller packets and path MTU discovery is not working, small requests may succeed while larger responses stall. A working handshake combined with incomplete page loads can be a reason to investigate MTU, but it doesn’t prove MTU is the cause.
Keep the default or original value
RecommendedFor your first test, use the app’s default handling or the MTU explicitly set in your existing configuration. First confirm that the keys, address, and Endpoint work. This gives you a baseline for later comparisons.
Best for: Initial setup, a working connection, or no signs of large-packet issues
Lower the MTU, changing one variable at a time
Only if the original value is higher, try a lower value—for example, change 1420 to 1380, then repeat the same request. These are troubleshooting examples, not universal optimal values. Change only the MTU each time and keep a record so you can restore it.
Best for: Small requests work, but large responses or connections on a particular network repeatedly stall
Restore the original value and retest
If lowering the MTU makes no difference, restore the original value and investigate UDP reachability, DNS, and server routing. A lower MTU can increase the number of packets, and lowering it further won’t solve every issue.
Best for: Changes have no effect, or another setting is causing the issue
For tunnels that need IPv6, don’t casually set the interface MTU below 1280; this is an important boundary for IPv6’s minimum link MTU. Keep other conditions consistent during testing—for example, use the same Wi-Fi network and request, and record what changes before and after. The values here explain the test method; they are not measured results or a performance guarantee for any particular connection.
What DNS and PersistentKeepalive each do
DNS resolves domain names to addresses; a successful WireGuard handshake doesn’t confirm that name resolution works. If the Endpoint uses a hostname, that hostname must also be resolved before the outer connection can be established. Distinguish between “the server hostname can’t be resolved” and “the destination can’t be resolved after the tunnel is up”—these may involve different query paths.
In standard WireGuard configurations, DNS is an auxiliary setting used by configuration tools, not part of the WireGuard handshake protocol itself. When using the node in Shadowrocket, don’t assume the DNS line in the original file fully controls how the app resolves names. Check the DNS settings in the active Config too. If the DNS server is reachable only through the tunnel, the route to it must be in place first.
- Domains fail, but a known IP is reachable: Check the resolver, query path, and IPv4/IPv6 results first. These are diagnostic clues, not a final conclusion.
- The Endpoint uses a hostname and won’t connect: First check whether the hostname resolves on the current network, then check the UDP port. Don’t start by changing tunnel DNS.
- The first request stalls after idle time: Check whether the NAT mapping has expired, then consider PersistentKeepalive instead of immediately regenerating keys.
- Recovery is slow after switching networks: Record behavior separately on Wi-Fi and cellular to see whether only one network restricts UDP traffic to the Endpoint.
PersistentKeepalive is measured in seconds. It sends keepalive packets while idle to maintain a NAT or firewall mapping. 25 seconds is a common reference interval, not a required value; in standard configurations, 0 disables periodic keepalives. Shorter intervals increase network activity while idle and don’t necessarily improve stability. Choose a value based on the existing configuration and observed network behavior.
Troubleshoot by failure stage, not by changing everything at once
When Home shows the connection as on, that confirms the system VPN tunnel has started; it doesn’t by itself prove that the WireGuard peer has responded. Interpret latency tests in context too: a single timeout can’t distinguish an unreachable UDP endpoint from mismatched keys or an unresponsive test destination. Pinpoint the stage where the issue occurs: connection setup, data transfer, DNS resolution, or recovery after idle time.
| What you observe | Check first | Next step |
|---|---|---|
| No valid response at any point | Endpoint, UDP port, public key pairing, PresharedKey | Test on both Wi-Fi and cellular, and check the server’s peer registration |
| There is a response, but the destination is unreachable | Tunnel Address, server forwarding, selected node, and policy | Confirm the request actually uses this node, then check server routing |
| Only domain access fails | Which stage handles Endpoint resolution and destination-name resolution | Compare resolution results and reachability by known IP under the same routing conditions |
| Small responses work, but large ones stall | Path MTU, IPv6 routing, and restrictions along the network path | Change only the MTU, repeat the same test, and record the result |
| Connection fails after being idle | NAT mapping, PersistentKeepalive, and network switching | Record how long it was idle, adjust keepalive based on the original configuration, and retest |
If you suspect a rule is bypassing the test node, go to Home → Global Routing, temporarily select Proxy, and confirm that the WireGuard entry being tested is selected. This reduces variables caused by rule-based routing; it won’t fix the node itself. After testing, restore the previous Config or routing mode so the diagnostic setting doesn’t remain in everyday use.
Will changing WireGuard to port 443 make it easier to connect?
Only if the peer is actually listening on that UDP port. UDP 443 and TCP 443 are different transport endpoints. A website loading over TCP 443 doesn’t prove that the current network allows UDP 443 to the same address. Don’t guess the port instead of checking the original configuration.
Can I use the same WireGuard settings on my iPhone and iPad?
Don’t assume both devices can use the same identity and tunnel address at the same time. The peer may update its endpoint based on the most recent valid packet, so reusing a configuration can make the devices interfere with each other. Use the identity and address your existing provider has assigned to each device. App purchase eligibility and protocol identity assignment are separate matters.
After troubleshooting, keep a change log that contains no keys: note which field you changed, its old and new values, the network used, and which request started working. If no network gets a valid response, revisit the Endpoint and peer identity pairing. If only one type of request fails, check DNS, routing, and MTU. This order makes it easier to reproduce results than changing several settings at once.