Shadowrocket WireGuard Setup: Private Key, Peer Public Key, Address, DNS, and MTU

1. Check the configuration source and field sections first

Shadowrocket’s WireGuard server type requires valid peer configuration; a server address alone is not enough to establish a connection. You’ll need an existing provider and configuration, or a WireGuard peer you manage. We don’t provide, sell, or recommend nodes or subscriptions. If you only have a standard subscription link, first confirm that it actually contains WireGuard entries. Don’t enter a subscription URL as the server address.

A typical WireGuard configuration has two sections: [Interface] and [Peer]. The first describes the local identity and tunnel interface; the second describes the remote peer and connection endpoint. Shadowrocket maps these values to the server editor. Field order and labels may vary in the current interface, so the original configuration keys are included below for easy reference.

Once you receive the configuration, keep a secure backup before entering it. Don’t post your Private Key, Preshared Key, or full subscription link in public support requests; these details may grant access to the connection. To check formatting, you can share the field length, whether it contains spaces, and which section it appears in—without revealing the key itself.

2. Private Key and Public Key: don’t mix up the local private key and peer public key

In [Interface], PrivateKey is the client’s private key and must match the client public key registered by the peer. In [Peer], PublicKey is the server’s public key, used to identify the remote peer. Both may look like Base64 strings, but they serve different purposes. Don’t identify them by appearance, and don’t enter the client’s own public key as the peer Public Key.

Standard WireGuard keys are usually 44 characters when Base64-encoded, often ending in =. A plausible length only suggests that the format may be valid; it doesn’t confirm that the keys match. When pasting, remove any leading or trailing spaces, quotation marks, and line breaks, but keep characters in the key such as +, /, and =.

• If you generate a new client private key, the peer must also register the new client public key derived from it. Changing the key on the device alone usually won’t restore the connection.
• Don’t copy the server’s PrivateKey from its [Interface] section into the client. Use the configuration specifically assigned to that client.
• If the original configuration has no PresharedKey, leave the field unset. Don’t use the PrivateKey or PublicKey as a substitute.
• Don’t let two devices use the same client identity at the same time. The peer may send replies to whichever endpoint was active most recently, causing the connection to drop intermittently between devices.

3. Address, Endpoint, and port: distinguish tunnel addresses from external endpoints

Address is the address inside the tunnel; Endpoint is the external destination used to connect to the remote peer. They aren’t interchangeable. For example, a client might be assigned 10.66.0.2/32, with 192.0.2.10:51820 as its Endpoint. The first identifies the client inside the tunnel; the second specifies where encrypted UDP packets are sent. This Endpoint uses a documentation-only address and cannot be used to connect.

/32 is an IPv4 prefix length, not a port. A single IPv6 address may use /128. If the interface asks for an IPv4 address in a separate field, don’t paste in the port or the full Endpoint. Enter an IPv6 address only if the original configuration assigns one and the network path supports it; don’t make one up.

In WireGuard, AllowedIPs defines the destination ranges a Peer can carry traffic for and the source ranges it accepts. It isn’t another way to write the client Address. Even if the original configuration includes 0.0.0.0/0 and ::/0, whether Shadowrocket routes a particular connection through this server also depends on Global Routing and Config rules. These values alone don’t prove that every app will use it.

4. Add WireGuard from Home and run a basic connection test

When setting things up for the first time, test a single server without changing routing, DNS, and MTU at the same time. That makes it easier to identify which change caused a problem. Use the server entry point below to add a WireGuard server; use Config for configuration files and rules. These are separate sections.

1. Select the type

   Go to Home → + → Type → WireGuard. When you return to the editor, make sure the type is still WireGuard before continuing.

2. Enter the connection details

   Enter the Endpoint host and port in their respective fields. For example, split the documentation-only value 192.0.2.10:51820 into an address and port. For an actual connection, use your own valid details.

3. Check the keys

   Enter the client Private Key and peer Public Key, then add the local tunnel address from the original configuration. Enter a Preshared Key only if one is explicitly provided.

4. Save and select the server

   Save the server, return to Home, and select it. The first time you connect, follow the system prompt to allow adding a VPN configuration. Authorization allows the system VPN configuration to be created; it doesn’t confirm that the remote peer is reachable.

5. Test the connection

   In Home → Global Routing, temporarily select Proxy, start the connection, and try a test destination you’re authorized to access. After testing, restore your previous Global Routing setting, then check your usual routing rules.

Selecting Proxy under Global Routing can reduce the number of rule-related variables, but it can’t bypass the server’s access permissions or network restrictions. Direct isn’t suitable for checking whether WireGuard is carrying traffic. With Config, confirm that the test destination matches a policy that uses this server. A VPN-connected status only indicates the local tunnel state; it doesn’t confirm a successful handshake with the peer or access to the service.

5. DNS and MTU: keep the original settings first, then adjust one at a time

DNS controls how domain names are resolved; it won’t fix an incorrect key. In traditional WireGuard configurations, DNS is usually interpreted by the app using the configuration—it isn’t part of the protocol handshake. When entering WireGuard details manually in Shadowrocket, don’t assume that the DNS value in the original file automatically becomes the resolver for the current configuration. Also check Settings → DNS and the DNS settings in the active Config; use the settings that are actually enabled.

• If the Endpoint is a hostname, it must be resolvable before the connection can be established. If the only available resolver is inside the tunnel that hasn’t been established yet, name resolution may depend on the tunnel itself. Check how DNS is intended to work in the original configuration.
• If access to a controlled destination works by IP address but fails by domain name, check DNS first. However, direct HTTPS access by IP may fail because of certificate or virtual host settings, so this symptom alone doesn’t prove DNS is the cause.
• If internal domain names must be resolved by a DNS server specified by the provider, copying a resolver from another network may leave the tunnel connected but internal resources inaccessible.

MTU is the maximum packet size an interface can carry. WireGuard adds outer encapsulation, so the underlying path’s capacity limits the size of packets inside the tunnel. If MTU is too high, small requests may work while large pages or uploads stall. If it’s too low, it can increase fragmentation and processing overhead. Packet loss or server load can cause similar symptoms, so slow loading alone doesn’t prove an MTU problem.

For each test, record the network type, original MTU, adjusted value, and result of the same operation. If lowering the MTU doesn’t produce a consistent improvement, restore the original value and check UDP reachability, packet loss, and server-side routing. Don’t change DNS, the port, and the MTU at the same time; even if access returns, you won’t know what fixed it.

6. Troubleshoot by symptom: check keys, then routing

Start troubleshooting with the basic connection requirements, then check access to services. DNS and routing rules only become relevant once the port is reachable, keys match, the address is correct, and the peer’s forwarding and return paths are working. If you manage the server, also check the peer’s latest handshake time and transfer counters. If a provider manages it, share the time and symptoms without exposing sensitive details.

If testing works under Proxy but fails after you restore Config, check which rule and policy actually match instead of generating new WireGuard keys. For example, DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains; IP-CIDR matches an IP address range, GEOIP matches against an IP geolocation database, and FINAL applies to connections that don’t match an earlier rule. Rules are processed from top to bottom. Check the active configuration to see which policy applies to the destination.