When configuring WireGuard, first distinguish the local Interface from the remote Peer: the Private Key belongs to the local device, while the Peer’s Public Key belongs to the remote side. The tunnel Address is not the server Endpoint. This guide is for users who already have a valid WireGuard configuration. It walks through field mapping, setup, and troubleshooting to help you check keys, addresses, the UDP port, MTU, and DNS in Shadowrocket—without guessing by repeatedly changing settings.
First, distinguish Interface from Peer
A WireGuard configuration typically contains an [Interface] section and one or more [Peer] sections. Interface describes the local device’s tunnel identity and address; Peer describes the other end of the connection. Before entering a provider-supplied configuration in Shadowrocket, sort the fields by these roles, then go to Home to add the record. Don’t paste a value based only on whether its name contains Key or Address.
This guide assumes you already have a provider and configuration of your own. Shadowrocket is a closed-source commercial app; a one-time app purchase does not include a network service plan. This site does not provide, sell, or recommend nodes or subscriptions. WireGuard fields work only when both ends are configured to match; purchasing the app does not create a usable remote Peer.
Interface: local device
- Private Key
- The local private key, corresponding to PrivateKey in the original configuration.
- Address
- The tunnel IP address and prefix length assigned to the local device.
- MTU
- The maximum IP packet size allowed on the tunnel interface.
- DNS
- The resolver address specified in the configuration; confirm where it actually applies.
The local key and tunnel address must come from the same valid configuration.
Peer: remote side
- Public Key
- The remote public key, corresponding to PublicKey in the Peer section.
- Endpoint
- The remote server address and UDP port.
- AllowedIPs
- The tunnel address range associated with this Peer.
- Preshared Key
- An optional preshared key agreed upon by both sides.
Do not enter the local public key as the remote Public Key.
Private Key, Public Key, and Preshared Key
PrivateKey and PublicKey are paired identity credentials. The local private key corresponds to a local public key, which must be registered on the remote side. Meanwhile, the Peer’s Public Key in the local configuration must be the remote public key. These keys let the two sides identify each other; don’t copy the same public key into every field.
A standard WireGuard key is 32 bytes and is commonly represented as a 44-character Base64 string, usually ending in =. The expected length only indicates that the value looks right; it doesn’t prove that the key belongs to your account or this Peer. Preserve the final character when copying, and remove any accidental quotes, line breaks, or surrounding spaces. Don’t include the entire PrivateKey = line in a field that accepts only the key value.
- Private Key: Copy this from the original configuration’s Interface section. Do not substitute the Public Key, and never show the private key in public screenshots or support requests.
- Public Key: Copy this from the target Peer section. If the remote side changes its key, update it here too; changing only the server address is not enough.
- Preshared Key: This is an optional additional symmetric key. If it appears in the original configuration, it must match on both sides. If it isn’t provided, don’t generate one and enter it on only one side.
- Regenerating the local private key: This changes the corresponding local public key. The existing authorization will not carry over unless the remote side updates its registered key as well.
Address vs. Endpoint: two different addresses
The Interface Address is an address inside the tunnel, such as 10.66.0.2/32. Here, /32 is the IPv4 prefix length, not a port. The Endpoint is the remote network address used to establish WireGuard communication, typically a domain name or IP address plus a UDP port. They serve different purposes. Even if the interface labels both as addresses, use their context to identify each one.
| Original configuration | Meaning | What to check when entering it |
|---|---|---|
Address = 10.66.0.2/32 | Local tunnel IPv4 address | Enter it in the local tunnel address field, keeping the prefix if the field requires it. |
Address = fd66::2/128 | Local tunnel IPv6 address | Enter this only if the original configuration assigns one; don’t make one up. |
Endpoint = 192.0.2.10:51820 | Remote IPv4 address and UDP port | In separate fields, enter the IP in Address and 51820 in Port. |
Endpoint = [2001:db8::10]:51820 | Remote IPv6 address and UDP port | If entering the address and port together, use square brackets to separate the IPv6 address from the port. For separate fields, follow each field’s format. |
The addresses in this table illustrate formatting only; they are not usable server addresses. Port 51820 is common, not mandatory. If the original configuration specifies another port, use that value. Don’t add https:// to an Endpoint or enter a subscription link. If you use a domain name, your device must be able to resolve it before it can send a WireGuard handshake to the remote side.
Add it in Home and test one variable at a time
Keep a copy of the original configuration before changing anything in the app. These steps cover manual entry of existing WireGuard parameters. If an existing subscription manages the record, first check whether an update will overwrite your changes. The interface may show tunnel parameters as separate fields; use the Interface and Peer roles to verify them, and don’t enter section headers from the configuration file as field values.
-
Organize the parameters
Copy the Interface PrivateKey and Address, along with the Peer PublicKey and Endpoint. Keep PresharedKey, MTU, and DNS too, if present. If the configuration has multiple Peers, first identify which one you need to enter.
-
Select the type
Go to Home → tap “+” in the upper-right corner → Type → WireGuard, then enter a label for the record and the remote address details. The label is for identification only; it isn’t used for key authentication.
-
Check each role
Enter the local Private Key, tunnel Address, and remote Public Key, then add the other parameters from the original configuration. Compare each field before saving, especially to make sure the Endpoint Port hasn’t been confused with the tunnel prefix length.
-
Test in isolation
Return to Home, select the record, temporarily set Global Routing to Proxy, and connect. Then try a destination known to be reachable. When the test is done, restore the previous Global Routing setting so the temporary setup doesn’t become your everyday configuration.
-
Check automatic connection
If the connection comes back after you disconnect manually, check Settings → On Demand. Temporarily disable any conditions that could trigger automatic connection during testing, then restore the settings you need when you’re done.
A connected status in the system VPN settings doesn’t mean the remote handshake succeeded. It confirms that a local VPN session has been established. To determine whether the remote side can send and receive data, check the actual request results, any available handshake records, and traffic counters. Don’t skip checking the keys and Endpoint just because the connection switch is on.
What AllowedIPs and Global Routing do
In a standard WireGuard configuration, AllowedIPs associates address ranges with a specific Peer and is also used to validate source addresses in received traffic. 0.0.0.0/0 represents all IPv4 addresses, and ::/0 represents all IPv6 addresses. Neither value guarantees that the remote side can forward traffic for that protocol family.
Shadowrocket’s Global Routing controls how the app chooses to handle requests. Proxy routes traffic through a proxy, Direct connects without one, Config follows the current configuration, and Scene follows the selected scene. AllowedIPs is not a domain rule in Config; don’t put DOMAIN-SUFFIX or FINAL in its address list.
- Works with Proxy but not Config: Check which rule the current Config matches, its target policy, and the selected server. Don’t assume the WireGuard fields are wrong.
- Works with Direct: This only shows that the destination is reachable over the current direct connection; it doesn’t prove that the WireGuard Peer is working.
- Only IPv6 destinations fail: Check that the tunnel IPv6 address, the Peer’s address range, and the remote IPv6 forwarding conditions are all configured correctly.
- Configuration with multiple Peers: Don’t mix Public Keys, Endpoints, and AllowedIPs from different Peers into one record. Keep each set of values paired as in the original configuration.
MTU: start with the original value, then adjust based on symptoms
MTU sets the maximum IP packet size the tunnel interface can carry. WireGuard encapsulates data in UDP, which also needs space for the outer IP and UDP headers and the protocol itself. For common data packets without additional extensions, the outer IPv4 overhead is about 60 bytes and the outer IPv6 overhead about 80 bytes. The usable value still depends on the access network and the full path.
1420 is a common reference value, not the best setting for every network. If the original configuration specifies an MTU, use that value first. If not, leave the app’s default handling in place. Consider adjusting MTU only if the handshake and small requests work but larger pages or uploads consistently stall. Lowering the MTU won’t fix an incorrect key.
- Note the current MTU and a reproducible destination. On the same network, test a small request, a larger page, and an upload.
- Keep the other fields unchanged. For example, reduce the MTU from 1420 to 1380, reconnect, and repeat the same requests. This is a troubleshooting example, not a measured result.
- If the symptoms don’t improve, restore the original value and check UDP reachability, DNS, and remote forwarding. If they do improve, test again after switching between Wi-Fi and cellular.
DNS: distinguish Endpoint resolution from DNS inside the tunnel
The WireGuard encryption protocol doesn’t provide DNS settings. In common configurations, DNS is an additional setting handled by the client. After entering the DNS value from the original file, check Shadowrocket’s current Config DNS settings to confirm the actual resolution path. The presence of a DNS field alone doesn’t mean every query will use that resolver.
Resolving an Endpoint domain before the connection and resolving a website domain after connecting are two separate steps. If the Endpoint is a domain and its specified DNS server is reachable only through a tunnel that hasn’t been established yet, you’ll need an available way to resolve it first. Check that the remote domain resolves over your current network, then confirm DNS inside the tunnel is reachable. This keeps the two types of failure separate.
- If the original configuration uses a private-network DNS address, confirm that the corresponding address range is reachable through the intended Peer. A private-network resolver may not be accessible over a direct connection.
- If the DNS field requires an IP address, don’t paste in a resolver URL containing
https://. These formats aren’t interchangeable. - If a domain fails but the same destination is reachable by IP, check DNS first. However, accessing an HTTPS site directly by IP can fail because of its certificate or site selection, so don’t rely on this as the only test.
- If a subscription update resets the parameters, check where the record comes from and review Config. Don’t change the key, DNS, and MTU all at once, or you won’t know which change affected the result.
Common issues: narrow down the cause by symptom
Why is there no traffic even though the Private Key is entered?
First compare the Peer’s Public Key and Endpoint, then confirm that the remote side has registered the local public key corresponding to your private key. If the original configuration includes a PresharedKey, enter that too. A correct local private key alone doesn’t prove the identities on both sides are paired.
Does the port have to be 51820?
No. Use the Endpoint port in your existing configuration, and confirm that the network path allows traffic over that UDP port. Changing the port to 443 won’t turn WireGuard into HTTPS or automatically solve UDP restrictions.
Small pages load, but larger pages keep spinning. What should I do?
Repeat the request on the same network to rule out an issue with the site itself. Keep the key and Endpoint unchanged, note the current MTU, and test a lower value once. If only domain requests fail, check DNS too; don’t assume MTU is the cause.
It stops working on cellular. Do I need to re-enter the keys?
First check UDP reachability and Endpoint domain resolution on the current network, then see whether Settings → On Demand is changing the connection behavior. Switching networks doesn’t require new keys. If the original configuration includes PersistentKeepalive, keep its original value; it can’t replace a reachable UDP path.
Can I use the same configuration on two devices at once?
It’s best to use a separate key and tunnel address for each device. If two devices use the same private key at the same time, the remote side may update its Endpoint based on the most recently received authenticated packet, causing traffic to switch between devices. Changing the MTU or DNS won’t solve this identity reuse issue.
When you’re done, keep a redacted record of the parameter sources, selected record, Global Routing mode, test network, and MTU before and after changes. Restore the original Config and On Demand settings, then test a real request again to confirm the results hold in everyday use.