Before adding WireGuard in Home, gather the complete settings provided by your existing service provider. This guide covers local identity, the remote peer, address ranges, MTU, and verification—in particular, the difference between the client’s private key and the remote public key. It also explains why a successful save, a visible VPN indicator, and a working request are not the same result. If you imported an existing subscription, use this guide to check its fields without re-entering everything.
1. Distinguish the local Interface from the remote Peer
Open the edit screen for an existing WireGuard entry in Home and check the original configuration’s [Interface] and [Peer] sections separately. The first describes the local tunnel identity and address; the second describes the remote endpoint. Shadowrocket may show these fields on the same screen, but they still belong to different sections. Don’t copy them blindly based on their order.
Enter the local client’s private key in Private Key, and the server’s public key in the remote Peer’s Public Key field. The server must also register the public key corresponding to this client’s private key. The two sides must have matching identity records to establish the intended encrypted connection. Entering the client’s public key in the remote public key field won’t authenticate correctly, even if the key format is valid.
In the original configuration, Endpoint = 203.0.113.10:51820 maps to the remote host in Address and the port in Port. This address is from a documentation-only example range and cannot be used for a real connection. Don’t enter the tunnel address under [Interface] as the remote Address, or replace a different port from your provider just because this example port is common.
2. Add WireGuard in Home and save each field
Tap + in the upper-right corner of Home, open Add Server, set Type to WireGuard, then enter the corresponding values. Use the steps below to check each field manually. Some advanced options may be collapsed depending on the layout; available fields vary by edit screen. The original configuration’s key names may differ from the form labels—for example, PresharedKey corresponds to Pre-shared Key.
-
Choose the type
Go to Home → + → Type → WireGuard. Select the protocol first, so you don’t accidentally enter a WireGuard key in the Password field for another protocol.
-
Enter the endpoint
Split the Peer’s Endpoint into Address and Port. If the value contains an IPv6 address, enter the address and port separately as required by the form. Don’t include the brackets used to separate the port in an ordinary address value.
-
Enter the keys
Enter the local private key in Private Key and the remote public key in the Peer’s Public Key field. If the original configuration includes a Pre-shared Key, enter the same agreed value on both sides.
-
Check the addresses
Map the Interface Address to the local tunnel address field, and check the IPv4 or IPv6 address and prefix length. Use the MTU from the existing configuration. Don’t enter the local tunnel address as a DNS or remote server address.
-
Save and verify
After saving, return to Home, select the entry, and start the connection. If iOS prompts you to authorize adding a VPN configuration for the first time, review the prompt and allow it. Then test with a request that you know uses this entry; a successful save alone doesn’t confirm that the connection works.
3. How Private Key, Public Key, and Pre-shared Key work together
When checking keys in the edit screen, copy them from the complete original configuration to avoid leading or trailing spaces, line breaks, or missing characters. Private Key, Public Key, and Pre-shared Key may all look like Base64 strings of similar length, but that doesn’t make them interchangeable. In particular, never copy the server’s private key to the client: the client needs the server’s public key.
Local identity
- Private Key
- The local client’s private key, from this client’s identity configuration.
- Client public key
- Derived from the local private key and registered on the server for this client’s Peer.
- Interface Address
- The address inside the tunnel, such as the documentation example
10.66.0.2/32. Use the value from your existing configuration. - What changes when you update it
- After changing the local private key, register the new client public key on the server as well.
The local private key is for this device’s identity. Don’t share it with other users or include it in troubleshooting screenshots.
Remote Peer
- Public Key
- The remote server’s public key, used to verify the identity of the other endpoint.
- Pre-shared Key
- An optional additional shared key; if enabled, it must match on both ends.
- Endpoint
- The reachable remote host and UDP port, entered as Address and Port.
- Allowed IPs
- The destination or source address prefixes associated with this Peer—not the endpoint address.
If the original configuration has no Pre-shared Key, don’t make one up and enter it.
In troubleshooting notes, include only necessary details such as whether a field is present, address prefixes, and the port. Redact Private Key, Pre-shared Key, and the full subscription URL. A Public Key isn’t a private key, but it may still identify a specific configuration; share only what’s necessary in public discussions.
4. What Allowed IPs and Global Routing control
In your existing WireGuard configuration, check AllowedIPs under [Peer]. It defines the IP prefixes associated with that Peer: for outgoing traffic, it determines which destinations can be sent to the Peer; for incoming traffic, it limits the inner source addresses the Peer may use. Some implementations also use it to create routes, so it isn’t just a note.
In Shadowrocket, Global Routing and Config rules determine which policy a request uses; separately, the WireGuard entry must be able to carry traffic to that destination. These operate at different levels. If the current WireGuard edit screen has an Allowed IPs field, check it against the original value. If it doesn’t, don’t enter it in Address, Public Key, or an unrelated field. Don’t assume all routing behavior from the original configuration automatically maps to Config rules.
| Configuration value | Address range | What to check |
|---|---|---|
0.0.0.0/0 | All IPv4 destinations | Doesn’t include IPv6, and doesn’t mean every Shadowrocket request will necessarily use this entry. |
::/0 | All IPv6 destinations | IPv6 also requires support from the tunnel address, remote forwarding, and network path. |
10.66.0.0/24 | A specific IPv4 subnet | An example address range only; it doesn’t replace the subnet assigned for your configuration. |
When testing in Home → Global Routing, use the two options below to distinguish whether the entry itself works from whether your rules select it. For everyday use, choose the option that fits your existing configuration. Direct in Global Routing bypasses proxy entries, while Scene provides context-based selection; neither should be confused with the address ranges in Allowed IPs.
Config: Use existing rules
RecommendedRequests follow the rules and policies in the current Config. Check which policies DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL point to, and confirm that the request you’re testing selects the intended WireGuard entry.
Best for: Existing rule configurations and everyday traffic routing by destination.
Proxy: Isolate rule selection
Temporarily use the current proxy selection to test a request, reducing variables from Config rule selection. This won’t fix incorrect keys, an unreachable endpoint, or remote forwarding issues, and it doesn’t guarantee that every type of traffic will work.
Best for: Briefly checking the selected entry. Restore your previous routing mode after testing.
5. Setting MTU: Keep the existing value first, then investigate path issues
Find MTU in the WireGuard edit screen and keep the value from your existing configuration unless there’s a reason to change it. MTU limits the size of each IP packet inside the tunnel. WireGuard’s outer encapsulation uses additional space, so the usable packet size inside the tunnel is usually smaller than the underlying link MTU. Don’t copy the Wi-Fi or cellular link’s MTU directly.
Consider path MTU as one possible cause only when the connection establishes and short requests work, but larger responses stall. A website simply failing to load isn’t enough to confirm an MTU issue; DNS, remote egress, and routing selection can produce similar symptoms. 1420 is a common starting point, not a universal setting for every network.
- Record the baseline first: Note the original MTU, current network, test destination, and failure symptoms so you can restore the setting later.
- Change one thing at a time: Adjust only the MTU, reconnect, and repeat the same test. Don’t change DNS, keys, and rules at the same time.
- Try a modest reduction if appropriate: For example, if the current value is
1420, you could compare it with1380if you understand the service configuration. These values are diagnostic examples only. - Keep IPv6 in mind:
1280is the minimum link MTU for IPv6. If you use IPv6, don’t treat an arbitrary lower value as a general fix. - Restore it if there’s no improvement: A lower MTU requires more packets to carry the same amount of data. “Lower is always more stable” is not a sound long-term setting rule.
6. Troubleshoot by symptom: Saved successfully, but still can’t connect
After selecting the saved WireGuard entry in Home, first check that the connection is enabled and that the request is using the intended policy, then review the result. The system VPN indicator means the relevant network extension is running; it doesn’t confirm a completed handshake with the remote endpoint. WireGuard also doesn’t necessarily generate traffic while idle, so send a repeatable test request yourself.
| Observed symptom | Check first | Next step |
|---|---|---|
| A field format error appears when saving | Check that keys are complete, the port is numeric, and the address is correctly formatted. | Copy each value from the original configuration, remove extra whitespace, and don’t make up new keys. |
| Requests keep timing out after connecting | Check the Endpoint, UDP reachability, remote public key, and the client public key registered on the server. | Keep the settings unchanged and test again on another available network. Ask your own service provider to check the handshake logs. |
| The remote end confirms a handshake, but requests still fail | Check the local tunnel address, Allowed IPs, remote forwarding, and egress configuration. | Check the address assignment first, then determine whether the destination is unreachable or its domain name fails to resolve. |
| Some domains fail while other requests work | Check DNS results, the policy matched in Config, and differences between IPv4 and IPv6 paths. | Compare DNS resolution and connection records for the same destination. Don’t assume the keys are at fault. |
| Small responses work, but large ones stall | Check the path MTU, packet loss, and the remote link. | Record the original value, then compare MTU settings one at a time. Don’t draw conclusions from a single request. |
Check automatic connection conditions in Settings → On Demand to avoid a condition reconnecting after you disconnect manually and skewing your test. On Demand controls when a connection starts; it doesn’t correct WireGuard settings. When troubleshooting is complete, restore your original Global Routing and On Demand settings and keep a record of the working values.
7. Final checks before saving and getting the app
Return to the entry’s edit screen and use this checklist for a final review before saving. If the entry came from an existing subscription, check after each update that key fields still match the server. Keep track of any differences between your local edits and the subscription source.
- Private Key is for this client, Peer Public Key is for the remote server, and the two haven’t been swapped.
- Enter Pre-shared Key only when both sides have agreed on one. If it isn’t configured, leave it disabled.
- Address and Port identify the remote endpoint; the local tunnel address uses the assigned address and prefix length.
- Allowed IPs matches the intended destination range, and Global Routing and Config select the expected entry.
- Keep an MTU value that has a clear basis, and record the original value for any changes made during testing.
To get Shadowrocket, visit this site’s genuine-app verification page first, then continue to the App Store. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. Shadowrocket is a closed-source commercial app sold as a one-time purchase; buying the app does not include a service plan. Connection settings come from your existing service configuration. Shadowrocket is primarily used on iPhone and iPad; compatibility with other Apple devices and system requirements are as listed on the App Store page.