Want DNS lookups to use HTTPS while Shadowrocket is connected on your iPhone? This guide explains where to check the DNS controls, how to enter a DoH resolver URL, and how to test the change without confusing a working VPN tunnel with a working DNS path. Menu labels and available options can vary by app version, so use the controls actually shown on your device. Before editing, record your current settings and keep a way to restore them.
1. What does DoH change in Shadowrocket?
DNS translates a hostname, such as www.example.com, into information a device can use to connect. With DNS over HTTPS (DoH), DNS queries are sent to a resolver through HTTPS rather than as ordinary unencrypted DNS requests. That describes the DNS transport; it does not encrypt every part of a connection or make a website itself private. HTTPS on the website and the routing selected in Shadowrocket are separate matters.
Does enabling DoH guarantee that every lookup on your iPhone uses it? No. The result depends on Shadowrocket’s DNS settings, the active connection and configuration, and how the app handles a particular request. iOS may also use system-level DNS behavior for traffic that is not handled by the app in the same way. Treat the setting as a change to test, not as proof that all apps and all network requests now use one resolver.
Before starting, make sure your existing connection works with the current DNS settings. If you already have your own service details, keep those unchanged while testing DNS. A resolver address is not a proxy server address: do not enter it under Home → Add Server, and do not change a server’s Type, Address, or Port to try to enable DoH.
2. Where are the DNS controls?
Start in Shadowrocket and open Settings, then look for DNS. The exact labels and layout can differ between app versions. Depending on the controls available, you may see a DNS server list, an encrypted DNS option, or a field for a DoH server URL. Do not assume that a control named DNS over HTTPS is present in every version; check the options displayed on your iPhone before following a particular label.
First note what is already selected. Record the current DNS mode and any existing server entries before you edit them. If you use a configuration that provides DNS settings, check whether the active configuration affects the values shown in Settings. Keep a copy of the original configuration using the backup or export options available in Config, if offered. If you cannot export it, take screenshots of the relevant settings so that you can restore them manually.
-
Check the baseline
In Home, note the active server and Global Routing mode. Open a webpage that normally works and record whether the current connection is on Wi-Fi or cellular.
-
Record DNS settings
Open Settings → DNS and write down the current mode, server values, and any enabled encrypted DNS option. Capture the screen before making changes.
-
Choose a resolver
Use a DoH endpoint you have independently chosen or been given by your organization. Confirm its exact URL and any access requirements with its documentation; do not guess the hostname or path.
-
Enter the endpoint
In the DNS controls, select the DoH option if shown and enter the complete HTTPS endpoint in the field intended for it. Preserve the scheme, hostname, and path exactly.
-
Save and retest
Save the setting, reconnect in Home if the app requires it, and test the same websites and network conditions you used for the baseline.
Some interfaces may offer a choice between an ordinary DNS server address and an encrypted DNS endpoint. These are different kinds of values. An IP address such as 192.0.2.1 is not a DoH URL, and a URL such as https://resolver.example/dns-query is only a format illustration, not a usable resolver. The example hostname uses a reserved example domain. Enter a real endpoint only after confirming it from the resolver’s own documentation.
3. How should you enter a DoH resolver?
A DoH endpoint is usually an HTTPS URL, not just a hostname. If the resolver documentation gives a path such as /dns-query, include that path. Avoid adding spaces, quotation marks, or extra query parameters unless the resolver explicitly requires them. If the app separates the server hostname from the URL path, follow the field labels and the resolver’s documented format rather than combining values arbitrarily.
Endpoint details
- Scheme
https://- Hostname
- Use the resolver’s documented host
- Path
- Include the documented path, if supplied
Copy the complete endpoint exactly; an illustrative URL is not a working resolver.
Before saving
- Menu
- Settings → DNS
- Field
- Select the DoH-specific field if available
- Port
- Use the endpoint’s documented port; HTTPS commonly uses 443
Do not edit the proxy server’s Address or Port to change DNS transport.
What if the resolver documentation lists a port explicitly? Follow that documentation and the format accepted by the app. HTTPS commonly uses port 443, but this is not a universal requirement for every endpoint. Do not append :443 automatically if the documented URL omits it or the app provides a separate port field.
After saving, verify that the intended option remains selected when you reopen Settings → DNS. If the value has reverted, check whether you edited a temporary field, whether a configuration controls the DNS choice, or whether the app rejected the URL format. Avoid changing unrelated settings to make the entry appear to save.
4. How can you test whether browsing still works?
A successful connection indicator in Home confirms that a tunnel is active; it does not prove that a resolver answered a query or that a webpage loaded. Test a normal browsing request after the DNS change. Use the same website, network, server, and Global Routing mode that worked before. Then test a second familiar domain to reduce the chance that a site-specific issue is mistaken for a DNS problem.
| Test | What to do | What the result tells you |
|---|---|---|
| Same-site retest | Reload the same URL you used before changing DNS. | A difference is useful to note, but does not by itself identify the cause. |
| Second domain | Open another familiar website in Safari. | If only one domain fails, check that site and its address before changing DNS again. |
| Network comparison | Repeat the test on Wi-Fi and cellular, where available. | A difference may point to network reachability, filtering, or resolver access. |
| Revert test | Restore the recorded DNS setting and retry the same request. | If browsing recovers, the new endpoint or its route deserves further checking. |
Do not treat a page loading once as definitive evidence that every DNS request used DoH. A browser or app may have cached a previous result, and a successful page can also be affected by routing and server behavior. To make a more useful comparison, close and reopen the affected app, retry the same domain, and note the time, network, and active Shadowrocket settings. If Shadowrocket provides request or DNS-related logs in your version, inspect them for the test request, but do not assume that every version exposes the same diagnostic detail.
For a controlled check, change only the DoH setting, then restore the previous value and repeat the same request. Keep the server, Global Routing mode, Wi-Fi or cellular connection, and URL unchanged. This does not measure resolver performance scientifically, but it helps separate a DNS-setting change from unrelated changes in the route or network.
5. What should you check if the change breaks browsing?
If webpages stop loading immediately after enabling DoH, restore the previous DNS setting first. This is a useful recovery step, not a failure: it confirms whether the new configuration is associated with the problem. Once browsing works again, verify the endpoint with its documentation, check for a missing URL path or typing error, and test again with only that one change applied.
- Check the endpoint: Confirm the full HTTPS URL, hostname, and path. Do not substitute a proxy address or a generic server IP.
- Check reachability: The network and active route must be able to reach the resolver. A resolver may be unavailable or blocked on one network even if it works on another.
- Check the active settings: Confirm that the intended configuration and DNS option are still selected. A configuration change can make a test use different settings than expected.
- Check the scope: If only one app or domain fails, test another domain and another app before concluding that all DNS lookups are broken.
- Restore the baseline: If the original DNS setting works and the new one does not, keep the original setting while you verify the endpoint or ask its operator for the correct format.
A DoH failure can look like a general connection failure because apps need successful name resolution before they can reach many websites. Conversely, a DNS error is not proof that the proxy server is offline. Check these layers separately: the iPhone’s basic network, the active Shadowrocket connection, DNS resolution, and the destination website. Change one layer at a time and repeat the same test.
Be cautious with automatic fallback options. If the DNS screen offers a fallback or secondary server, check what that option does before enabling it. A fallback can help restore lookups when the primary resolver is unreachable, but it can also mean that some requests use a different resolver. Use only settings whose behavior you understand and can verify in the app.
6. Quick answers before you finish
Use these checks to avoid common setup mistakes. The wording refers to typical troubleshooting situations; the available controls depend on the Shadowrocket version installed on your iPhone.
Can I paste a resolver IP into the DoH field?
Not if the field expects a DoH endpoint. Use the complete HTTPS URL documented by the resolver. An IP address alone does not specify the HTTPS hostname and path.
Do I need to change my proxy server’s port?
No. Keep the server Address, Port, Type, and authentication details unchanged. Configure DNS only in the DNS controls, and use the port required by the resolver endpoint if the app asks for one.
Should I leave DoH enabled if pages stop loading?
Restore the DNS settings you recorded, then retry the same URL. If it loads again, verify the endpoint and its reachability before reapplying the change.
The safest setup is a measured one: record the original DNS settings, enter a verified endpoint in the DNS control intended for DoH, and test the same requests under the same network conditions. If the result is worse, restore the original value before troubleshooting further. Keep DNS settings separate from server details, and do not infer that an active tunnel alone confirms successful name resolution.