How to Configure WireGuard in Shadowrocket: Private Key, Endpoint, MTU, and More

1. Add a WireGuard profile from Home

A WireGuard profile in Shadowrocket requires a matching set of parameters. A remote address and port alone are not enough to connect: the remote peer must also have the public key corresponding to your Private Key and assign an address to your tunnel. This guide assumes you already have a valid configuration of your own and does not cover how to choose a service.

Tap “+” in the top-right corner of Home to open Add Server. Set Type to WireGuard, then review the fields shown for that type. The server address, port, and keys may appear in separate fields; the sections below explain the Endpoint first, followed by keys, the tunnel address, and advanced settings. Field order and optional fields vary by interface, so follow what you see. Do not enter another protocol’s Password or UUID in a WireGuard key field.

1. Prepare your configuration

   Find the Interface and Peer sections in your own configuration and keep an unmodified copy. PrivateKey belongs to your device; PublicKey under Peer belongs to the remote peer. Do not mix them up.

2. Select the protocol

   Go to Home → “+” → Add Server → Type → WireGuard. Confirm the type before entering the address and keys so you don’t carry over assumptions from another protocol.

3. Enter each field

   Use your own configuration for the server address, port, Private Key, remote Public Key, and tunnel address. For MTU, DNS, and any optional keys, use the original values whenever possible.

4. Save and test

   After saving, return to Home, select the profile, and turn on the connection switch. The first time, follow the system prompt to allow adding a VPN configuration, then use Connectivity Test to check connectivity.

2. Endpoint: Separate the host from the port

Endpoint is the publicly reachable location of a WireGuard peer, made up of a hostname or IP address and a UDP port. Your original configuration may combine them as vpn.example.com:51820. If Add Server shows separate Address and Port fields, enter the host in the address field and 51820 in the port field. Don’t paste the full string into both fields.

The table uses documentation-only example domains and addresses; they cannot be used to connect. In a combined IPv6 address-and-port format, square brackets distinguish the address from the port. When entering the values separately, follow the address field’s requirements. Don’t add https:// before the host or append a web path.

51820 is a common example port, not a requirement for every WireGuard service. Use the port in your own configuration. WireGuard uses UDP; being able to reach a TCP port at an address does not prove that the UDP port with the same number is available. A hostname that fails to resolve, an incorrect port, or UDP restrictions on the current network can all result in no response. That symptom alone does not identify the cause.

3. Private Key, Public Key, and optional keys

Private Key is the private key for your device. It determines your device’s public key, which the remote peer must already recognize. In the remote peer’s configuration, Public Key usually refers to the server’s public key, used to identify the server. It is not the public key derived from your Private Key. Both may appear as long Base64 strings, so their appearance alone doesn’t tell you which is which.

• Private Key: When copying, avoid including the field name, quotation marks, line breaks, or leading and trailing spaces. Never share a real private key in public feedback, screenshots, or test text.
• Public Key: Use the peer’s public key from your own service configuration. It is not a server hostname, account password, or subscription token.
• Pre-shared Key: If this optional field appears in your configuration and in the current interface, both sides must use the same value. If it isn’t set in the original configuration, don’t add a random value.

The expected length only means the text may have the right format; it doesn’t prove the key matches the remote peer. An incorrect public key, a mismatched private key, or a different Pre-shared Key can all prevent communication. Check each value against the original configuration instead of attributing every failure to the port.

4. Tunnel address: Address is not Endpoint

Fields that both refer to an “address” can serve entirely different purposes. The Endpoint address locates the public peer, while Address under Interface is the address your device uses inside the tunnel. If your original configuration contains 10.66.0.2/32, it denotes the client’s internal address and prefix length. Don’t enter it in the public server host field.

Don’t choose a tunnel address based on these examples. Client addresses on the same remote peer usually need to be unique; reusing another device’s full identity and address can cause intermittent communication. To use multiple devices at once, use the separate configurations assigned to each device by the service.

AllowedIPs is not the same as Shadowrocket’s global routing mode. In WireGuard, it determines how peer address ranges are handled. Whether Shadowrocket sends an app connection through that server also depends on Global Routing and the rules in Config. If your original configuration includes AllowedIPs but the current editor has no field with that name, don’t paste it into Address or DNS. First check the currently supported import methods and configuration instructions.

5. MTU and DNS: What to check when problems persist after connecting

MTU limits the size of packets handled by the tunnel interface. If the value is too high, encapsulated packets may exceed the path’s capacity. If fragmentation or error reporting along the path isn’t handled correctly, small requests may work while larger ones stall. Treat this as a troubleshooting lead—not a conclusion based only on slow page loads.

• Keep the original value first: If your configuration specifies an MTU, start with that value. If it doesn’t, leave the app’s default behavior unchanged. Don’t start by changing several advanced settings at once.
• Change one variable at a time: For example, if the original value is 1420 and you’ve confirmed a large-packet issue, temporarily try 1380 and repeat the same request. This is a troubleshooting example, not a universally optimal value.
• Record the results: Note whether each request completes or times out, along with the network used. If there’s no consistent improvement, restore the original value and continue checking DNS resolution, routing, and the remote peer’s status.

DNS resolves domain names to addresses; it doesn’t fix incorrect keys or ports. DNS in the original WireGuard configuration usually refers to the resolver used through the tunnel. Actual DNS behavior in Shadowrocket is also affected by DNS settings in Config and related routing rules. Adding a DNS address to the server profile does not guarantee that every domain lookup will follow the same path.

The internal DNS address must also be reachable over the relevant network path. If testing by IP succeeds but requests by domain name fail, check the DNS result and reachability first. However, websites may rely on the correct hostname and TLS information, so testing an IP address directly in a browser is not a substitute for a complete domain-name test.

6. Global Routing: Tell protocol issues from rule issues

After saving a WireGuard profile, select that server in Home. Turning on the connection switch means the system has enabled the corresponding VPN configuration; it does not mean the remote peer has responded successfully. Before testing, confirm that traffic is actually routed through this profile. Otherwise, you may see a “successful” test that actually went through Direct.

If you normally use Scene, first confirm which server and rules the current scene applies before interpreting test results. Restore your usual mode when troubleshooting is complete. Under Settings → On Demand, check whether the on-demand connection conditions could change the connection state during testing. On Demand does not replace WireGuard authentication or correct misconfigured parameters.

In Config, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches based on an IP address’s geographic location, and FINAL handles connections that haven’t matched earlier rules. Rules affect routing in order, so check the policy that actually matched rather than judging the protocol’s status only by the switch at the top of Home.

7. Troubleshoot by symptom—don’t change every field at once

Establish a baseline on a stable network, then cross-check with Connectivity Test and real-world requests. A single latency reading doesn’t mean every destination is reachable, and a failed test doesn’t automatically mean the keys are wrong. Use the table to guide the order of checks, not to infer a single cause from one symptom.

If the profile comes from a subscription you already use, manual edits may be overwritten when the subscription updates. Save the original parameters before making changes, and use clear notes to distinguish test profiles from subscription-managed ones. When reporting an issue to your own service provider, include the test network, symptoms, and field names you checked. Don’t share a real Private Key, Pre-shared Key, or full subscription URL publicly.

Use this final check order: confirm the remote endpoint is reachable, verify the keys belong to the correct peers, confirm the tunnel address matches, check that DNS resolution works, and ensure the target traffic actually uses that server. Only fine-tune MTU after these basics are verified, so advanced settings don’t mask a basic configuration error.