This guide is for users with their own provider and subscription who can’t get a server list in Shadowrocket. Check URL integrity, request results, response format, provider status, and update conditions in that order to distinguish retrieval, parsing, and connection failures. Keep your existing configuration and test one change at a time to avoid losing evidence by repeatedly deleting or refreshing.
1. Tell subscription failures apart from connection failures
Shadowrocket is a paid client for Apple platforms, available exclusively on the App Store. It is developed by Shadow Launch Technology Limited and sold as a one-time purchase. Buying the app does not provide a connection service; this guide assumes you already have your own provider and subscription. Check the App Store page for compatible devices and system requirements.
Updating a subscription retrieves and parses server information; it does not test whether each server can connect. An empty list in Home and a timeout with servers already listed are different issues. For an empty list, check the subscription URL and response. For a timeout, investigate the server address, port, authentication details, and network reachability.
A problem at any stage can cause an update to fail or leave the list unchanged. A successful HTTP request only means the server returned content; it does not mean the content is a parseable subscription. Likewise, existing entries do not prove the latest update succeeded.
- Empty on first import: Check the pasted URL, subscription format, and how many entries the provider actually returned.
- Worked before, now failing after an update: Check whether credentials were reset, subscription access changed, or the provider’s API is under maintenance.
- Entries are listed but won’t connect: Stop retrying the update and investigate the connection error for the specific server.
2. Check the full URL and preserve its encoding
Copy the subscription URL intended for Shadowrocket from your provider’s account page. Don’t copy the account home page, an order page, or the short label shown on a button. Subscription URLs often contain credentials. Similar-looking URLs may return an account page or server data, and they are not interchangeable.
https://example.com/sub?token=xxxx
The example above is intentionally unusable. Check that the actual URL is complete, from https:// through the final character, especially the query parameters after ?. When a URL is forwarded in a chat, punctuation at the end, line breaks, or truncation can get included by mistake. Copy it again from the original source rather than trying to reconstruct it.
- Check for whitespace: The URL should have no spaces at either end or actual line breaks within it. Text wrapping in a field does not mean a line break was inserted into the URL.
- Preserve capitalization: Paths, parameter names, and credentials may be case-sensitive even when the domain is not. Don’t change their case.
- Preserve encoding:
%2B,%2F, and%3Dmay be part of the credentials. Don’t decode or re-encode them manually. - Watch for HTML escaping:
&in webpage source is not a parameter separator to paste as-is. Use the provider’s copy function whenever possible. - Identify the URL type: A single-server share and a subscription URL are different kinds of input. Don’t add every kind of content using Subscribe.
3. Verify the import again in the app
In Shadowrocket, Home is where you view and manage servers, Config is for configuration files, and Settings is for app preferences. Add a subscription URL in Home using Subscribe; importing it as a Config file does not parse it as a server subscription. Before testing, note the existing subscription name, entry count, and error message. Don’t clear everything first.
-
Keep existing entries
In Home, confirm that the original subscription and its entries are still there. If your current connection relies on them, preserve the existing state instead of starting by deleting and re-creating the subscription.
-
Choose Subscribe
Go to Home, tap “+” in the top-right corner, then choose Subscribe under Type. Enter a recognizable name and paste your full subscription URL into the URL field.
-
Save and update
After saving, return to Home, pull down to update, and wait for the request to finish. Note whether it succeeded or failed and whether the entry count changed. Don’t repeatedly refresh while the request is still in progress.
-
Check the list
Clear any search in Home and expand the relevant subscription group to make sure filters or a collapsed group aren’t hiding the list. If the name hasn’t changed, compare the entry count as well.
-
Separate any follow-up issue
If server entries appear, subscription parsing returned results. Test the connection separately; don’t classify a connection timeout as an empty subscription.
If your provider reset an existing subscription URL, update the URL saved for that subscription instead of keeping multiple groups with the same name. If you need to test in parallel, give the test entry a clear name and remove it afterward so you don’t mistake the old list for new results.
4. Use the HTTP status and response to narrow down the cause
If request details are available, note the status code first, then check the response body. The descriptions below are standard HTTP status meanings; Shadowrocket may not display them verbatim in every situation. Use them only when the actual error details or your provider’s records show the corresponding status. Don’t submit a URL containing full credentials to a third-party site just to get a status code.
HTTP 401 Unauthorized
Cause: The request lacks valid authentication, or the subscription credentials have expired. Fix: Check the current URL in your provider account. If needed, generate new credentials and update the saved URL.
HTTP 403 Forbidden
Cause: The server rejected the request, possibly because of account permissions or access restrictions. Fix: Ask your provider to check the rejection using the request time. Don’t assume every 403 means the subscription has expired.
HTTP 404 Not Found
Cause: The request path doesn’t exist, possibly because the URL was truncated or the API path changed. Fix: Copy the current subscription URL again and check its path and query parameters. Don’t guess the API endpoint name.
HTTP 429 Too Many Requests
Cause: The server is rate-limiting requests. Fix: Stop repeatedly pulling down to refresh. If the response includes Retry-After, wait for the specified time; otherwise, ask your provider when to try again.
Remember: HTTP 200 doesn’t mean the subscription is valid
If your provider confirms the response is a login page, verification page, or error message, fix access and permissions before updating the subscription. Repeatedly changing server protocol settings won’t resolve a parsing problem.
Even a non-empty response might contain only a notice, an empty data set, or a format that the current endpoint doesn’t support. Base64 is an encoding method; it doesn’t guarantee valid server information inside. Don’t add characters, repeatedly decode the entire response, or prepend a protocol prefix. Ask your provider to confirm the response format and the number of valid entries.
5. Ask your provider to verify access and response format
Being able to sign in to your account doesn’t guarantee that the subscription endpoint is currently returning server information. Subscription eligibility, data limits, expiration, maintenance, and credential resets can all affect the response. After payment or renewal, confirm that the change has taken effect on your account instead of relying on repeated refreshes.
- Check eligibility: Is the relevant service active in your account? Are there data limits, a suspended status, or a pending status update?
- Check credentials: Was the subscription URL recently reset? Is Home still using an old token?
- Check the response body: Does the endpoint return server data, or a login page, verification page, error message, or result with no entries?
- Check the format: Get the current subscription format supported by Shadowrocket. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocol names; changing a name alone does not convert the format.
- Check for changes: Did the endpoint domain, path, certificate, or response format change? Does your provider need to fix the generated response?
When contacting support, include the exact error, time and time zone, network used, whether this was the first import, and whether the old entries remained or the count changed after updating. This is more useful than simply saying it “doesn’t work.” Before sharing a screenshot, hide the full subscription URL, token, server passwords, and other authentication details. Use your provider’s private support channel for account-related checks.
6. Rule out network and timing issues, then test once more
Fetching a subscription also requires a network connection. DNS failures, TLS certificate errors, connection timeouts, or Wi-Fi that requires a web login can prevent the response from being retrieved. Check that the device date and time are correct and complete any required network sign-in before updating once. If you see a certificate error, check the device time and ask your provider to inspect the certificate; disabling security checks is not a solution.
Global Routing controls how connection traffic is handled; it can’t fix an invalid subscription format. Settings → On Demand controls on-demand connection behavior, not subscription updates. If testing requires temporarily stopping connections, note the original settings and check whether On Demand might reconnect. Restore the original settings when you’re done troubleshooting.
- Keep inputs consistent: Use the same subscription URL you just verified, and note the current time and entry count in Home.
- Complete one request: Update once on the current network and wait for a clear result. Don’t change the URL, connection settings, and network at the same time, or you won’t know which change mattered.
- Change only the network: If possible, switch from Wi-Fi to cellular or vice versa, then test once more. If only one network fails, check its DNS and access conditions first.
- Avoid rate limits: If requests are being restricted or the service is under maintenance, wait until the time specified by your provider. Don’t set up frequent automatic updates.
- Verify the result: Confirm the expected entries appear in the subscription group, then test the server connection separately. If the list is still empty, give your provider the times and error results from both tests.
Narrow it down: change one condition at a time
If the URL stays the same and switching networks resolves the issue, investigate the network path. If both networks return the same authentication error, check the account and credentials. If a valid list appears but connections still fail, troubleshoot the server connection.
By the end, you should be able to pinpoint the stage: incomplete URL, request not reaching the server, access denied, unsupported response format, or server connection failure. Following this order helps preserve configurations that still work and avoids mistaking a problem with the provider’s response for an app installation issue.