The key to setting up WireGuard is knowing which values belong to your device and which belong to the remote peer: Private Key is local, the Peer Public Key is remote, Endpoint is the remote public address, and Address is your local tunnel address. This guide shows how to enter an existing WireGuard configuration in Shadowrocket and troubleshoot “connected but can’t access anything” by checking Allowed IPs, routing mode, and DNS.
1. Understand Interface and Peer before you start
A standard WireGuard configuration usually has two sections: [Interface] and [Peer]. The first describes your device’s identity and tunnel address; the second describes the remote endpoint. Even if Shadowrocket lays out the fields differently from the configuration file, match each value to the correct section. Do not swap the keys.
Start with the complete configuration provided by a service you already use, and make sure it is still valid. An Endpoint or a Public Key by itself is not enough to connect: the server must also have the Public Key associated with your Private Key registered and allow the tunnel address assigned to your device. This guide covers importing and checking configuration only; it does not provide, sell, or recommend nodes, subscriptions, VPN services, or invite codes.
In short: identify which section each value belongs to, then enter it
Check the Interface and Peer sections of the original configuration separately. If you cannot tell which side a key belongs to, confirm with the configuration provider first. Do not swap keys and repeatedly retry the connection.
2. Enter the fields in Add Server
These steps use the Home screen on iPhone and iPad. Go to Home → + → Add Server → Type → WireGuard, enter your device’s details first, then configure the Peer. If your version shows Endpoint as separate address and port fields, or puts Peer in a separate editing section, enter each value according to its meaning. Do not paste the entire configuration into an address field.
-
Choose the type
On Home, tap “+” in the upper-right corner to open Add Server, then set Type to WireGuard. Add a note that helps you identify the entry and distinguish it from existing servers.
-
Enter your device details
Map Interface’s PrivateKey to Private Key and Address to your local tunnel address. Keep the prefix length at the end of the address, such as
10.66.0.2/32. -
Enter the remote peer details
In the Peer section, enter the Peer’s PublicKey and Endpoint. If the address and port appear in separate fields, enter the host address and numeric port separately.
-
Check the options
Check Allowed IPs, Preshared Key, MTU, DNS, and Persistent Keepalive against the original configuration. Do not copy optional fields from another account if they were not provided.
-
Save and test
After saving, return to Home, tap the dot to select this server, then turn on the connection switch. The first time, follow the system prompt to allow adding a VPN configuration, then run Connectivity Test.
If a server was generated from a subscription, check its original parameters first. Updating the subscription may regenerate the entry and overwrite manual changes. Record the original values before troubleshooting so an update does not make you think your changes were retained. Do not use a regular subscription URL as a WireGuard Endpoint.
3. What to enter for Private Key, Public Key, and Preshared Key
Private Key is your device’s private key. It comes from Interface’s PrivateKey and should not be shared in public discussions or screenshots. WireGuard keys are commonly represented as 44-character Base64 strings, but the right length only suggests the format may be valid; it does not prove the key matches the one registered on the server.
| Original configuration field | Corresponding field | What to check |
|---|---|---|
| Interface / PrivateKey | Private Key | Your device’s private key; copy it in full without spaces or line breaks |
| Interface / Address | Your device’s tunnel address | Not the public Endpoint; keep the CIDR prefix |
| Peer / PublicKey | Peer’s Public Key | Remote public key, not your device’s public key |
| Peer / PresharedKey | Preshared Key | Optional preshared key; must match on both ends |
| Peer / Endpoint | Remote address and port | Must point to a reachable remote UDP service |
The Peer’s Public Key is the remote public key. Do not enter the public key derived from your own Private Key here. Your device’s Public Key lets the remote side identify your device; the Peer’s Public Key lets your device identify the remote side. They serve opposite purposes.
Preshared Key is an additional shared secret. If the original configuration does not include one, leave the field empty. If one side has a key and the other does not, or the values differ, the handshake will fail. It is not a login password and cannot be replaced with a subscription token.
4. Endpoint and Allowed IPs: addresses and routing are different
Endpoint is where the remote side receives WireGuard UDP packets, for example 192.0.2.10:51820. This is a documentation-only example address and cannot be used to connect. 51820 is a common port, not a required value. Use the port in the original configuration; do not change it to 443.
- If the app shows separate address and port fields, enter only the hostname or IP address in the address field and the port number in the port field.
- If Endpoint uses a domain name, that name must resolve before the connection can be established. If resolution fails, the WireGuard handshake has not started yet.
- For a combined IPv6 Endpoint, use square brackets to separate the address from the port, for example
[2001:db8::10]:51820. This address is also for documentation purposes only. - Address is your local address inside the tunnel; Endpoint is the remote entry point. They are not interchangeable.
Allowed IPs corresponds to AllowedIPs in the original configuration and specifies the tunnel IP ranges associated with that Peer. WireGuard uses it to select which Peer should receive outgoing traffic and to check whether incoming packets have a source address belonging to that Peer. It is not a list of allowed website domains, and you cannot enter example.com directly.
0.0.0.0/0
::/0
10.20.0.0/16The three lines above show example ranges for all IPv4 addresses, all IPv6 addresses, and one specific IPv4 subnet. They are alternatives, not values you must copy together. If your existing configuration allows only 10.20.0.0/16, changing it to cover all addresses will not automatically enable internet forwarding on the remote side. The remote side still needs the appropriate routes, forwarding, and access permissions.
5. Configure MTU, DNS, and Persistent Keepalive in order
MTU sets the maximum size of IP packets carried by the tunnel interface; it is not a bandwidth limit. If the original configuration specifies an MTU, start with that value. If not, keep the default behavior and avoid repeatedly changing it right away. Encapsulation and path MTU vary across outer networks, so a value that works on one network may not work everywhere.
| Setting | Purpose | When and how to use it |
|---|---|---|
| MTU | Limits tunnel packet size | Investigate if small requests work but large ones stall. For example, change 1420 to 1380, then retest the same destination. |
| DNS | Selects the DNS server used for domain lookups | Make sure the resolver is reachable through the current route, and check which DNS settings are actually in effect. |
| Persistent Keepalive | Sends periodic keepalive packets to help maintain the NAT mapping | Use the value in the original configuration; 25 seconds is a common example, not a required setting. |
DNS is not part of the WireGuard handshake protocol. The client or configuration tool often handles the DNS value in a configuration file, so its presence in the original file does not prove Shadowrocket is currently using it. Check the DNS setting in the server entry and Settings → DNS. If the active Config file also includes DNS settings, check how those settings interact.
If the DNS address is inside the tunnel, such as 10.66.0.1, make sure it is covered by Allowed IPs and that the relevant connections are actually routed through the tunnel. Otherwise, the Endpoint may be reachable and the tunnel may be established while domain lookups still time out. Do not change resolvers without checking whether the resolver itself is reachable over the current route.
- When adjusting MTU, change one value at a time. Reconnect, make the same type of request to the same destination, and note whether it improves.
- Small requests succeeding while large files stall is a clue to investigate MTU, but the cause may also be remote forwarding or the destination service. Do not treat this symptom alone as a definitive diagnosis.
- Persistent Keepalive can help maintain mappings for idle connections, but it cannot fix an incorrect public key, a wrong port, or a remote server that has not registered your device’s public key.
6. When testing, distinguish Proxy, Config, and Direct
An enabled connection switch on Home only means the client’s connection process is active; it does not mean every destination is going through WireGuard. Before testing, tap the dot to select the server you just saved, then check Global Routing. The modes below describe Shadowrocket’s routing behavior, not protocol speed.
Proxy: isolate the effect of rules
RecommendedTemporarily sends connections handled by the client through the selected proxy route, reducing the effect of Config routing rules on this test. It cannot expand the Allowed IPs range or provide missing remote forwarding.
Best for: first-time testing of a WireGuard configuration with internet forwarding
Config: check which rules match
Routes traffic according to the currently enabled configuration file. First check which rule and policy match the destination, then confirm whether the connection should use WireGuard. FINAL handles connections that did not match an earlier rule.
Best for: restoring everyday rule-based routing after confirming the basic connection
Direct: compare with a direct connection
Uses a direct route. If a webpage opens in this mode, that does not prove WireGuard works; it can help determine whether the destination is already reachable over your current network.
Best for: distinguishing a local network issue from a tunnel routing issue
Scene in Global Routing applies routing according to the configured scene. During troubleshooting, check which policy it actually uses rather than relying on the mode name alone. If the connection comes back automatically after you disconnect it manually, also check Settings → On Demand. On Demand controls connection behavior; it does not fix incorrect WireGuard settings.
- Note the current Global Routing mode, select the server you want to test, turn on the connection, then run Connectivity Test.
- Test a destination covered by the current Allowed IPs that you know you can access. If the configuration only allows access to an internal network, test an internal service.
- If handshake or traffic logs are available, distinguish “handshake not completed” from “traffic fails after the handshake.” A single latency reading is not a substitute for verifying that the service works.
- Switch back to Config and access the same destination again. Check whether the routing policy, DNS, or connection result changes.
7. Common setup problems and fixes
Private Key saved successfully, but why won’t it connect?
A successful save only means the input was accepted. Return to Home, edit the entry, and check that Interface’s PrivateKey, Peer’s PublicKey, and PresharedKey are in the correct fields. Then confirm that the remote side has registered the public key corresponding to this Private Key.
Should the Endpoint port always be 51820?
No. 51820 is only a common example; use the UDP port specified in your existing configuration. If address and port have separate fields, do not include the colon and port in the address field. Testing over another trusted network can also help identify whether UDP is reachable on the current network.
I can access internal addresses, but regular websites won’t open. What should I check?
First check whether Allowed IPs includes only internal subnets, then confirm whether the service is supposed to provide internet forwarding. If public internet access is expected, check Global Routing and DNS next. Do not add all address ranges as a catch-all fix.
Why did my manually changed MTU revert after updating the subscription?
A subscription entry may be regenerated from remote settings when updated. Compare the parameters with your notes from before the update, then make changes through the configuration source for the service you already use. If you create a separate manual test entry, give it a clear note so you do not accidentally select the updated entry instead.
After troubleshooting, keep only the field-check notes you need. When sharing an issue, hide sensitive information such as Private Key, Preshared Key, and subscription tokens. Remove account-identifying details before showing addresses or error messages. Check each item in order—identity keys, Endpoint, Allowed IPs, DNS, then MTU—instead of changing several fields at once to make the cause easier to find.