This guide is for users who already have a subscription from their own provider. When Shadowrocket updates a subscription, it first fetches the response, then identifies its contents, and finally creates server entries. A failure at any stage can leave the list unchanged. Keep existing entries and check the URL, account status, request path, and content format in that order. This helps distinguish a failed fetch from content that could not be parsed, without deleting configurations that may still work.
1. Tell an empty list from an update or connection failure
A subscription URL fetches a set of server configurations; it is not the connection address for a single server. A successful subscription update does not mean every server in it can connect. Likewise, a server that still works does not prove the subscription endpoint is currently reachable. Before troubleshooting, expand the relevant subscription group in Home. Check whether the entire group is empty or whether entries remain but Connectivity Test returns no valid result.
- Note what happened: Record the exact error, when it occurred, which network you were using, and whether the entries changed after updating. “It doesn’t work” is not specific enough.
- Keep existing entries: Don’t delete the subscription, Config, or servers that still connect. If you need to save a screenshot, hide the subscription URL, password, and token.
- Check what’s visible: Make sure the relevant group is expanded in Home. If a search or filter is active, clear it before deciding the list is empty.
- Test one subscription at a time: Update a single group and check the result. A successful update in another group does not verify this subscription.
If the entries appear normally but connections time out, check the server settings and connectivity instead of the subscription encoding. The steps below focus on failures to fetch or parse subscription content.
2. Check the URL, its completeness, and where you imported it
Copy the full URL again from your own provider’s subscription management page, then compare it with the address saved in Shadowrocket. Don’t use an account login page, order page, or management page URL from your browser in place of the subscription endpoint. Query parameters containing token often provide authentication. A missing character or an accidental line break can change the response.
https://example.com/sub?token=xxxxThe address above is a fictitious example to illustrate the format; it cannot provide server entries. https:// is the scheme, example.com is an example hostname, and /sub is an example path. Anything after the question mark is a query parameter. Keep the real path and parameters exactly as provided by your service provider; don’t modify them based on this example.
- Check the beginning and end: Remove spaces, quotation marks, and explanatory text added during copying. Make sure no trailing parameters were left out.
- Check the characters: Full-width punctuation cannot replace the standard
:,?, or&. Don’t decode or re-encode%escape sequences in the URL unless instructed to do so. - Check the content type: A single server share and a subscription URL are different kinds of input. Pasting several server shares together does not turn them into a valid subscription endpoint.
- Check where you imported it: Add subscription entries in Home. Config is for configuration files and rule management; don’t import an arbitrary subscription URL as a Config file URL.
- Check whether credentials changed: If you reset the subscription URL or token, the old address saved in the app won’t update automatically. Check and replace the saved value.
3. Check provider status and the HTTP response
A complete URL does not guarantee that the endpoint will return server configurations. An expired account, changed access permissions, endpoint maintenance, or request rate limits can all change the response. First check your account page to confirm the subscription is active, entries are available, and the URL hasn’t been reset. Your provider must confirm these details; the client can’t fix server-side permissions or data.
The following are HTTP status messages that may appear in request logs or server diagnostics. They are not a promise of the exact wording shown in Shadowrocket. If the app does not display a status code, don’t assume that an empty list means any one of these errors.
Error: 401 Unauthorized
Cause and fix: The endpoint did not accept the current authentication details. Check whether the subscription token is missing, expired, or has been reset, then update using the current URL from your account page.
Error: 403 Forbidden
Cause and fix: The server denied the request. Ask your provider about account permissions, source restrictions, and endpoint requirements. Repeatedly changing server connection settings won’t resolve this.
Error: 429 Too Many Requests
Cause and fix: The request rate limit was triggered. Stop refreshing repeatedly, wait for the period specified by the server or your provider, then try again. Check whether multiple devices are updating automatically at the same time.
Diagnosis: Fix the endpoint response before troubleshooting parsing
If you’ve confirmed that the endpoint returns an authentication error or an access restriction page, restore a valid response from the subscription endpoint first. Changing protocols, editing rules, or reimporting the same URL cannot recover server data that the endpoint didn’t return.
4. Test update timing and network paths separately
Updating a subscription makes a network request that depends on DNS resolution, a connection, and HTTPS verification. Being able to open regular websites on your current network does not mean the subscription host is reachable. A browser that’s already signed in may also display content using cookies. A request made by the app with the subscription URL may not have the same login state, so “it opens in my browser” is only a clue.
- Connect to the network first: If the current Wi-Fi requires web authentication, complete it before manually updating in Home. HTML returned by a captive portal cannot be parsed as subscription content.
- Record one update attempt: Pull down to refresh in Home and wait for the request to finish. Note the result. Don’t repeat the action while the request is still in progress.
- Change one variable at a time: If possible, test the same URL over Wi-Fi and cellular. Keep the other subscription settings unchanged to see whether the issue depends on the network.
- Check the update path: Look at the update-related options in Settings → Subscribe. If the current app shows Update via Proxy, note its state and confirm that the selected path is available. Check the value shown in your version of the app rather than assuming a default.
- Use a proxy path only if a connection is available: To update through a proxy, first connect using an existing server and confirm that it works. Then update the subscription. If the list is empty and no other server is available, enabling proxy updates alone cannot create a working connection.
- Check for automatic connection interference: Check whether Settings → On Demand automatically reconnects on the network you’re testing. Note the original setting so an automatic reconnection isn’t mistaken for a disconnected state. Restore the original setting after testing.
Global Routing in Home controls how traffic is handled. Proxy, Direct, Config, and Scene are not four subscription formats. In particular, seeing Proxy does not prove that a subscription request went through a proxy. Check the subscription update option, connection status, and actual request result separately. Rules in Config cannot fix an empty response from the server.
5. After a successful fetch, check the response and its encoding
A successful HTTP request does not guarantee that the subscription was parsed. Even with a 200 OK status, the response body could be a login page, maintenance notice, empty text, or content that isn’t meant for the import method you’re using. Check the output type provided by your service provider instead of repeatedly downloading the same response.
| Response | What it may mean | What to check next |
|---|---|---|
| The body contains HTML | A login page, network authentication page, or endpoint error page | Confirm that the subscription endpoint returns configurations without relying on a browser login session |
| The response body is empty | The endpoint returned no entries, or the account currently has no available data | Ask your provider to confirm the number of entries and the endpoint status |
| The response is Base64 text | It may be a collection of encoded server shares | Confirm the data is complete, the encoding is valid, and the decoded result is supported subscription content |
| Only some entries appear | Some entries may have missing fields, an incompatible format, or be filtered out | Clear any filters first, then ask your provider to check the output format of the missing entries |
Base64 is an encoding, not encryption, and does not guarantee a valid subscription. Truncated text, added explanatory text, or an error page after decoding can all cause parsing to fail. Don’t upload a full subscription to an online decoder. Ask your own provider to check the original response and encoding, and to supply output compatible with Shadowrocket.
- Keep the original content: Don’t manually add line breaks, remove symbols that look unnecessary, or combine multiple responses before importing them again.
- Check the format and fields: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different protocol types. Renaming a set of parameters won’t turn it into another protocol.
- Tell missing entries from connection failures: Missing fields such as the server address, port, or authentication details can prevent parsing. If all fields are present but Connectivity Test fails, check the actual connection conditions.
- Confirm the intended output: If your provider offers multiple export options, choose the subscription output they explicitly say is compatible with Shadowrocket. Don’t treat an arbitrary configuration document as a server list.
6. Common questions and checks after recovery
The list is still empty after copying the URL again. Should I delete the old subscription?
Not yet. Keep the existing group, confirm the new URL was saved correctly, then update that subscription and note any error. Deleting it only removes existing entries; it won’t fix endpoint authentication, network timeouts, or content format issues.
Why can I see the content in a browser but the app can’t parse it?
First check whether the browser is showing raw configuration data or an account webpage. The browser may have a login cookie or follow a redirect to a management page. Ask your provider what the subscription URL returns directly and whether it requires additional authentication.
Will turning on the connection switch before updating definitely fix it?
Not necessarily. An existing connection must work, and the update path must match the current settings. Changing the path won’t fix an expired token or an invalid response format. First note the update option in Settings → Subscribe, then run one controlled test.
The list is back. What else should I check?
In Home, confirm that the target group contains entries. Choose a server and run Connectivity Test, then verify actual access. Restore any On Demand or other settings you temporarily changed for troubleshooting. If only some entries returned, check for filters and ask your provider about the output.
When contacting your provider, share when the issue occurred, which network you used, whether the update went through a proxy, the exact error, and whether the list was entirely empty or only missing some entries. Don’t share a full token, password, or server credentials. This site does not provide, sell, or recommend servers or subscriptions. Your provider must confirm subscription validity and server-side output.
Success criteria: verify fetching, parsing, and connecting separately
If the update completes and entries appear in the group, fetching and parsing have recovered. Then use Connectivity Test and verify actual access. Record these three results separately so you can resume troubleshooting at the point of failure if the issue happens again.