This guide is for users with a WireGuard configuration from their provider who are ready to enter the settings in Shadowrocket. First, distinguish your device’s Private Key from the peer’s Public Key. Then enter Address, Endpoint, MTU, and DNS, and use one-variable-at-a-time tests to tell a key mismatch, blocked UDP traffic, DNS resolution failure, or oversized packets apart.
WireGuard keys: distinguish your device from the peer
WireGuard uses key pairs to identify both ends of a connection. Each end has its own Private Key and a Public Key derived from it. The Private Key stays on its device; the Public Key is shared with the peer. In a client configuration from your provider, [Interface] and [Peer] contain different kinds of information. Don’t swap them just because both sections contain a Key.
In Shadowrocket, your device’s Private Key proves its identity, while the peer’s Public Key identifies the remote end. The server must also register the client Public Key corresponding to your Private Key. If you replace the Private Key without updating the server’s registration, the remaining settings won’t establish the correct connection.
Key takeaway: identify which end each key belongs to
Before entering the settings, label Interface PrivateKey and Peer PublicKey in your configuration as “local private key” and “server public key.” If either is missing, check with your provider. Don’t substitute a key from the other end.
How Private Key, Public Key, and address fields map
The table below maps standard WireGuard configuration fields to their meanings. Field order in Shadowrocket’s editor may change, so match by meaning rather than position. In particular, distinguish Address from the remote server address: Address is an internal tunnel address, while the server address comes from Endpoint. They’re usually different.
| Setting | Source | How to enter it |
|---|---|---|
| Private Key | PrivateKey in [Interface] | Use the private key assigned to your device. Keep the complete Base64 value, including a possible trailing =. Don’t add spaces or line breaks. |
| Public Key | PublicKey in [Peer] | Enter the remote peer’s public key—not your client’s public key or a subscription login credential. |
| Address | Address in [Interface] | Enter the tunnel address and prefix assigned by your provider, such as 10.66.0.2/32 in the documentation example. Don’t replace it with a similar address of your own choosing. |
| Server address and port | Endpoint in [Peer] | Enter the host and port in their respective fields. The port must match the server; 51820 is a common example, not a requirement. |
| Preshared Key | PresharedKey in [Peer] | This is an optional additional shared key. If the server uses one, the value must match exactly. If none was provided, don’t use the Private Key as a substitute. |
| MTU | MTU in [Interface] or provider instructions | Use the supplied value if available. If none is specified, keep the app’s default; don’t assume a value that works on one network is best for all networks. |
| DNS | DNS in the configuration and provider’s DNS instructions | Check whether the resolver is reachable only through the tunnel, then compare that with the DNS settings in your current Shadowrocket configuration to understand the actual resolution path. |
Treat your Private Key as sensitive information. When describing an issue, you can share the error text, network type, and field names without credentials. Don’t post your full private key, Preshared Key, or subscription link. A public key doesn’t need to be kept secret like a private key, but there’s no need to include account or address details in public reports.
Add WireGuard from Home
Gather your complete configuration from your provider before entering anything. An Endpoint or public key alone isn’t enough to build a working configuration; the client identity registered on the server, assigned address, and permitted routes must all match. The steps below use manual setup; interface labels remain in English.
-
Choose the protocol
Go to Home → tap “+” in the top-right corner → Type → WireGuard. Choose the protocol first, then enter its fields so you don’t leave WireGuard settings in another protocol’s editor.
-
Enter the remote endpoint
Enter the host from Endpoint in the server address field and the port in Port. For example, if the configuration shows
vpn.example.com:51820, enter the host and51820separately. This is a format example, not working connection information. -
Check the keys
Enter your local Private Key and the remote Public Key. Add the Preshared Key if one was provided. Compare each value with the original configuration and check for extra quotation marks, spaces, or field names copied along with it.
-
Enter the internal address
Enter Address as provided, keeping the required prefix length. Use the assigned IPv4 and IPv6 addresses as given; don’t remove IPv6 information just because your device is currently connected to an IPv4 network.
-
Save and test
Check optional settings such as MTU, save the entry, and select it from Home. For a brief, controlled test, set Global Routing to Proxy and turn on the connection. When testing is complete, restore your usual setup, such as Config.
If the entry was created from an existing Subscribe subscription, first confirm that the subscription includes a WireGuard entry. A subscription update may overwrite fields it manages. Keep the original configuration and note any manual changes. Don’t repeatedly edit the entire subscription just to preserve a test setting, and never include full subscription credentials in troubleshooting screenshots.
Address, AllowedIPs, and rule-based routing operate at different levels
Address is the internal address of the local tunnel interface. In 10.66.0.2/32, /32 represents a single IPv4 host address; it isn’t the remote Endpoint and doesn’t mean all network traffic automatically enters the tunnel. This address usually matches the client configuration on the server. Changing it to /24 at random won’t fix a connection problem.
In standard WireGuard configurations, AllowedIPs is associated with selecting destination addresses for a peer and checking source addresses. Shadowrocket’s Global Routing and Config rules determine which policy an app request uses. Don’t assume that routing in a system-level WireGuard configuration has the same effect as rule-based routing in Shadowrocket.
0.0.0.0/0covers the entire IPv4 address range, and::/0covers the entire IPv6 address range. These specify address ranges, not DNS servers.- Global Routing → Direct uses a direct-connection mode, so it isn’t suitable for testing whether the selected WireGuard entry is carrying requests.
- Global Routing → Config processes requests using the current configuration. If a request matches
DIRECT, selecting a WireGuard entry doesn’t prove that the request went through it. DOMAIN-SUFFIX,IP-CIDR,GEOIP, andFINALare rule-matching keywords. Don’t enter them as a Private Key, Public Key, or Address.
Choosing and testing an MTU
MTU is the maximum size of an IP packet an interface can carry. WireGuard encapsulation adds overhead for the outer IP, UDP, and protocol headers, so the usable size inside the tunnel is usually smaller than the outer link’s MTU. Other encapsulation may also exist along the path; Wi-Fi signal strength and broadband speed alone can’t tell you the right MTU.
1420 is a common starting point for WireGuard MTU. 1280 can be useful as a diagnostic comparison, but neither is right for every network. If your existing configuration specifies a value, use it. If not, keep the default. Investigate MTU only if small requests work but larger pages or transfers stall.
- Record the original MTU, current network, Global Routing mode, and test target so you can restore the baseline.
- First confirm that the same entry can complete an actual request on the current network. If there’s no communication at all, check the keys, Endpoint, and UDP reachability before trying different MTU values.
- If large transfers consistently stall with the default or
1420, try1380. If the problem persists, compare with1280as a diagnostic. Change only the MTU each time, reconnect, and repeat the same test. - Record results on both Wi-Fi and cellular networks. If a value works on one but not the other, the network paths likely differ; that alone doesn’t mean the other network’s configuration is wrong.
These values are examples of a test sequence, not results measured by this site. If lowering the MTU restores access, it may point to a path MTU, fragmentation, or packet-handling issue, but repeat the test to confirm. If it makes no difference, restore the original value and investigate other layers. Don’t assume that a lower MTU is always more reliable as a permanent setting.
Check both the DNS resolver and its route
WireGuard doesn’t define a universal DNS configuration distribution protocol. In common configuration files, DNS is information for the client or configuration tool; the WireGuard handshake doesn’t automatically negotiate a resolver. To determine which DNS settings Shadowrocket actually uses, also check the DNS configuration in your current Config and the app settings.
If Endpoint is a hostname, it must be resolvable before the tunnel can be established. Relying entirely on DNS that’s reachable only through the tunnel can create a catch-22: the tunnel is needed to resolve the name, but the name must resolve to establish the tunnel. Also, a provider’s private DNS server may not be reachable through Direct, even if its address is valid.
- Only the Endpoint hostname fails: Check its spelling and confirm that the current network can resolve it. Changing the Public Key won’t fix a DNS resolution failure.
- The tunnel carries traffic, but regular domain names fail: Check the DNS address used by the current configuration and how it’s reached. Make sure a private DNS resolver isn’t being sent over a direct connection where it can’t be reached.
- Only some websites have problems: Check IPv4 and IPv6 reachability as well as which rules match. An AAAA record doesn’t mean the current tunnel has an IPv6 exit.
- After changing resolvers: Reconnect and retry the same destination, allowing for app or system caches. One successful load of a previously opened page doesn’t confirm that the new setting is active.
Common setup issues and troubleshooting order
An enabled connection switch only indicates that the system VPN session is in the corresponding state; it doesn’t by itself prove that WireGuard has successfully exchanged data. Troubleshoot in this order: complete configuration → Endpoint and UDP → matching keys → address and routing policy → DNS → MTU. This is more informative than changing settings at random.
Should I enter the Public Key I generated?
You need the remote peer’s Public Key. Match it to PublicKey under [Peer] in your provider’s configuration. The server must register your own public key. If you generate a new key pair, have the server register the new public key too; changing only the local Private Key isn’t enough.
Will changing Port to 443 guarantee a connection?
No. Port must match the UDP port the remote server actually listens on. Setting it to 443 doesn’t turn WireGuard into HTTPS or TCP. Restore the port from your configuration, then test the same entry on Wi-Fi and cellular to see whether only one network path fails.
Can I copy the example address 10.66.0.2/32?
Don’t use the example as your assigned address. Open the original configuration, find Address under [Interface], and enter the value you were actually assigned. If it’s missing, check with your provider. Reusing another device’s configuration can also create identity or address conflicts; confirm whether you need a separate assignment.
Why does reconnecting seem to use the old entry?
Return to Home and check the selected entry and Global Routing. In Config mode, also check which policy group is selected. If the connection state is restored automatically, go to Settings → On Demand and review the connection conditions. Note them and temporarily disable any relevant conditions during testing, then restore them afterward.
What should I do if a subscription update changes the settings?
First check whether Subscribe manages the entry, then compare the update with your original configuration. Keep test values separate from the settings you intend to use. If the subscription keeps supplying an incorrect Address or keys, check the configuration with your provider rather than manually overriding it after every refresh.