Shadowrocket Subscription Empty or Parse Failed: URL, Provider, and Update Checks

First, tell the difference between an empty subscription, a parse error, and a connection failure

Updating a Shadowrocket subscription retrieves content from an existing subscription URL and turns it into entries. A connection test, by contrast, attempts to connect using a specific entry. A successful update doesn’t mean the connection will work, and a failed connection doesn’t prove the subscription URL is invalid. First identify which step failed; don’t lump every issue under “the server doesn’t work.”

• The subscription group appears, but it contains no entries: Check whether you updated it, whether the group is expanded, and whether the response actually contains valid entries.
• A parse error appears during an update: Check the response format first. A login page, error message, or empty response can’t be parsed as a valid subscription list.
• The update takes a long time, then fails: First check network access to the subscription domain, DNS, and the TLS connection. Then confirm the server is available.
• Entries appear, but won’t connect: Check the individual entry’s address, port, authentication, and transport settings. Don’t keep refreshing the subscription as a substitute for diagnosing the connection.

Use Home to manage entries and connections, Config to manage configuration files, and Settings for related options. Changing DOMAIN-SUFFIX or FINAL in Config won’t turn a login page into subscription content. Keep your existing configuration and limit checks to the subscription itself so you can tell whether each step helped.

URL format: Verify the full address from Subscribe

Copy the URL again from your provider’s subscription management page. This is safer than manually patching a broken link. Make sure it’s the subscription URL—not an account homepage, login page, or billing page. Query parameters in a subscription URL often provide authentication, and even a single missing character can change the server’s response.

1. Keep a record of the current setup

   On Home, note the subscription name, the number of existing entries, and the exact error from this attempt. Don’t delete a subscription that still has working entries or overwrite your existing Config.

2. Copy the full URL

   Copy the full subscription URL from your provider’s page. Check the scheme, domain, path, and every parameter after the question mark. Remove any spaces accidentally included when copying, but don’t alter the parameters.

3. Check the entry type

   To add a new subscription, tap “+” in the upper-right corner of Home to open Add Server. Set Type to Subscribe, then paste the address into URL. If you already have a subscription, open its edit screen and verify the URL instead of creating duplicate groups.

4. Save, then update

   Save and return to Home, then pull down to update. Wait for the request to finish before checking the group’s entry count and any message. Don’t trigger repeated refreshes while a request is still in progress.

5. Record the result

   Note the time of the update, the network you used, and the exact message. Change only one condition next time—for example, switch networks—so you can tell what made the difference.

https://example.com/sub?token=xxxx

The address above illustrates URL structure; it isn’t a working subscription. Parameters after ?, & separators, and percent-encoding may all be part of the original URL. Don’t treat an ellipsis shown by a messaging app as part of the link, and don’t decode and rebuild the URL yourself. If you copied the literal & from a page’s source, return to the page and use its copy option to get the address again rather than guessing how to change the token.

[Check]

ss://, vmess://, vless://, and trojan:// usually represent a single shared entry, not an HTTPS subscription URL that can be fetched regularly. Import a single entry using the appropriate method. Changing its prefix to HTTPS won’t enable subscription updates.

Response content: An HTTP success doesn’t guarantee a successful parse

Even after a request reaches the server, you still need to check what the server returned. The HTTP status code describes the request outcome; subscription parsing also depends on whether the response body contains recognizable entries. So if a URL opens in a browser, that only confirms it returned a response. A visible page alone doesn’t prove the subscription is valid.

Some subscriptions return an encoded list of entries; others return readable text. Don’t assume it’s corrupted just because it looks like a long string of characters. Conversely, a well-formatted HTML page can return HTTP 200 without containing any importable entries. Ask your provider to confirm that the endpoint supplies subscription data Shadowrocket can recognize, rather than instructions intended to be read in a browser.

• The response body is empty: Ask your provider to confirm whether the account should currently have entries, whether the endpoint generated any content, and whether a cache is still returning an old response.
• The response is a login or verification page: A browser may show content using an existing login session, but the app’s subscription request doesn’t share that session. Get a subscription URL intended for use in a client.
• The response contains an error message: Follow its instructions to check authorization, account status, or request limits. Keep the original text; don’t paste it into another field in Add Server.
• Only some entries appear: Ask your provider to check the sharing format, required fields, and protocol parameters for the missing entries. A partial import doesn’t prove all the content is correct.

Provider-side checks: Use the original response; don’t guess at the cause

The cards below list standard HTTP response phrases. They don’t mean Shadowrocket will necessarily display the exact same wording. Follow a branch only if the corresponding status code appears in an app message, request diagnostic, or your provider’s records. A “parse error” alone doesn’t prove authentication failed or access was restricted.

If your provider confirms the endpoint is back online but the client still shows an empty subscription, determine whether the update failed to retrieve new content or retrieved content that was still empty. Share the update time, status code, change in entry count, and exact message to help them investigate. Before sharing screenshots or logs, hide subscription tokens, passwords, UUIDs, and other authentication details. Don’t post a full URL in public forums.

Update timing: Network paths, proxy updates, and automatic connections

Updating a subscription requires access to its domain; connecting an entry requires access to that entry’s server. The domains and network paths may differ. An entry connecting successfully doesn’t mean the subscription domain is currently reachable directly, and an accessible subscription domain doesn’t mean every entry’s server is working.

If a direct request times out but an existing entry still works, connect through that entry first. Then go to Settings → Subscribe and check Update via Proxy. Enable it if needed, then return to Home and update. This changes how subscription requests access the server; it won’t fix an invalid token, an empty response, or an unsupported server-side format. Without a working connection, enabling it alone can’t create a working route for updates.

• Connect to the network first: If a new Wi-Fi network requires web-based sign-in, complete that first, then return to the app and update. Don’t mistake the sign-in page for a subscription response.
• Check the current connection: Proxy, Direct, Config, and Scene under Global Routing are traffic-handling modes, not subscription format options. Check the current setting; there’s no need to cycle through them to try to parse the subscription.
• Check automatic connection conditions: Settings → On Demand triggers connections based on conditions; it isn’t a subscription update switch. Note whether it changes the connection state, and keep the network path consistent while testing.
• Try again on a different network: Retrying on another available network can help identify a network path issue. Note the changed condition, and don’t change the URL or other settings at the same time.
• Allow time for server-side changes: If your account or subscription content has just changed, use the effective time confirmed by your provider. There’s no universal wait time that guarantees the issue will be fixed.

Don’t disable certificate validation to fix a subscription update error. For a TLS-related message, first check your device’s date and time and verify the subscription domain, then ask your provider to check the certificate and certificate chain. If the problem occurs only on one network, keep the message from that network as diagnostic information—it’s more useful than bypassing a security check.

Frequently asked questions: Final checks that preserve your data

Finally, check each item in order: full URL → Subscribe type → response body → server status → update network → retry timing. Change only one variable at a time, and record the result after each request finishes. If you need to report the issue, the checklist below describes what happened without exposing your full authentication details.

1. Say whether the subscription was empty on first import, an existing subscription update failed, or some entries were missing after an update.
2. Provide the time, connection type (such as Wi-Fi or cellular), and whether Update via Proxy was enabled.
3. Include the exact message and any verifiable HTTP status code. If there’s no status code, say “not available” rather than guessing.
4. Give the entry count before and after the update, and say whether your provider confirmed that valid entries should currently be available.
5. Share only necessary details with your provider through a private support channel. Before posting screenshots publicly, hide tokens and other authentication fields.