Shadowrocket Subscription Not Parsing or Showing No Servers: Check the URL, Provider Response, and Update Timing

If a subscription appears empty or fails to parse, check the URL and encoding, confirm its status with your provider, then review update timing and network conditions. Troubleshoot step by step.

At a glance

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.

Read the subscription URL Send a network request Receive the response Parse server entries Display the server list

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.

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.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

200
A successful HTTP request? Check the response body’s format
401 / 403
Check authentication and access permissions first
429
Access is restricted? Stop refreshing repeatedly

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.

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.

  1. Keep inputs consistent: Use the same subscription URL you just verified, and note the current time and entry count in Home.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Verify Shadowrocket on the App Store