Shadowrocket subscription updates first need to receive a response, then parse the server entries it contains. Assuming you already have your own provider and subscription, this guide checks things in order: preserve the current setup, verify the URL, inspect the response, test the network, and review auto-update settings. First distinguish a failed request from an unsuitable response or a successfully returned empty list. This helps identify the next step without repeatedly deleting the subscription and losing a useful reference.
1. Tell Update Failures, Parse Errors, and Empty Lists Apart
A failed subscription update does not mean existing servers have stopped working, and an empty list does not necessarily mean no request was sent. An update involves a network request, authentication, content parsing, and displaying the list. When one step fails, note what happened at that step instead of treating every issue as a bad URL.
Go to Home first and make sure you are viewing the intended subscription group, not another group or filtered results. Then check whether the existing entries are still there with an update error, or whether the target group is actually empty after the update. A visible profile in Config does not mean the subscription is working; profiles in Config and server lists in Home are separate things to check.
- Note when you manually updated, whether you were on Wi-Fi or cellular, and the full error message.
- Record the number of entries in the target group before updating. If you have a recoverable configuration, keep a copy; do not start by deleting the subscription.
- Manually update the target subscription once, then check the error message and list. Avoid updating multiple sources at the same time.
- If only one entry fails to connect, check that entry’s address, port, and authentication fields instead of treating it as an empty subscription.
2. Check the Subscription URL and Response Format
A subscription URL retrieves a set of entries; it is not a provider account page or a single shared connection link. ss://, vmess://, vless://, and trojan:// usually describe a single connection. Being importable does not make them subscription URLs that can be refreshed. An HTTPS URL is not necessarily a subscription either: login pages, help pages, and error pages can all use HTTPS.
https://example.com/sub?token=xxxxThese are examples of formats that cannot be used to connect. When checking the URL, compare the scheme, hostname, path, and query parameters. Make sure you have not dropped anything after ?, changed & to the literal text &, or included punctuation, quotation marks, or line breaks from a chat message. Do not remove a token just because it looks long, or change percent-encoding without a reason.
- Where to copy it: Copy the Shadowrocket subscription URL again from your own provider account page. Before replacing the saved URL, compare it with the old one.
- Response format: Make sure the server returns subscription content the app can recognize, not a full configuration page, account instructions, or a web form.
- Sensitive data: A token may grant access. Do not share the full URL in public screenshots, online decoding tools, or public forums.
- What browser access tells you: If a URL opens in a browser, that only confirms the browser received some kind of response. The browser’s existing login session may not be included in the app’s subscription request.
If the browser shows a login form, CAPTCHA, or expiration notice, resolve the account issue first. Do not save webpage text and import it as a subscription. Text that looks encoded is not necessarily parseable; confirm that the URL is an export endpoint for the relevant client.
3. Check HTTP Responses for Expiration, Restrictions, and Empty Content
Your provider account’s expiration date, traffic status, whether the subscription URL has been reset, and request rate limits can all affect the response. Check each item in your own account, then use the actual response to guide your next step. The examples below are standard HTTP response text. They apply only when the error details or server logs show the corresponding status; Shadowrocket may not display these exact words.
Error: 401 Unauthorized
Cause: The request was not authenticated, possibly because credentials are missing or expired. What to do: Check your subscription URL in your own account for a reset. Copy the full URL again and retry once.
Error: 403 Forbidden
Cause: The server rejected the request, possibly because of account permissions, source restrictions, or an access policy. What to do: Check your account status and send your provider the redacted error and time it occurred. Do not assume this is an app parsing issue.
Error: 429 Too Many Requests
Cause: The request triggered a server rate limit. What to do: Stop refreshing repeatedly. If the response includes Retry-After, wait as directed, then test once.
Error: 503 Service Unavailable
Cause: The server cannot process the request temporarily, possibly due to maintenance or overload. What to do: Keep your existing entries, retry later, and check whether your provider has posted a service status update.
Even 200 OK only means the HTTP request was processed successfully; it does not guarantee that the response contains valid servers. The body may be empty, contain account instructions, or be an HTML page. If the entry count drops from nonzero to zero, check both whether your account still has entries available and whether the subscription export returned the expected content.
Bottom line: Check the response before changing parsing-related settings
If the response is actually a login page, permission notice, or empty body, changing rules or server protocols will not restore missing entries. First restore a valid response from the subscription URL, then manually update once.
4. Test the Network Path One Variable at a Time
Whether a subscription update request can reach its destination is separate from whether a server in the subscription can be reached. Existing entries may still connect even when the subscription URL is inaccessible; a successful update does not guarantee that every new entry can connect. Keep your current configuration, change one condition per test, and record the result.
- Check your basic connection: Complete any web sign-in required by your current Wi-Fi. If the network itself is unavailable, fix the connection first, then retry the update in the app.
- Switch networks: If possible, switch from Wi-Fi to cellular and update the same URL once. Record whether each attempt succeeds; do not change the URL at the same time.
- Check the subscription update setting: Go to Settings → Subscribe and review the update options shown in the current interface. If
Update via Proxyis available, note its original setting. Test updating through the proxy only if you already have a working connection, then compare the result with the original setting. - Check certificates and device time: If you see a certificate or TLS error, verify the device’s date and time and confirm the destination domain is correct. Do not hide the error by disabling certificate verification.
Do not treat Proxy, Direct, Config, or Scene under Home → Global Routing as switches for the subscription parsing format. These options affect routing behavior; they cannot restore a truncated token or turn HTML into a server list. To determine whether an update request goes through a proxy, check the update-specific setting and the current connection state. Do not infer the route for every request from a single routing mode name.
Likewise, changing DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL is not the first step when the response is empty. Check related configuration only after confirming that the current route affects the subscription domain, and save a copy before making changes.
5. Check Auto-Update Timing After a Successful Manual Update
Auto-update cannot make an invalid URL or unavailable network work. First complete a manual update with the app in the foreground and confirm that the expected entries appear. Then review the auto-update options and intervals actually available under Settings → Subscribe. Labels may differ between interfaces, so use the options shown on your device; do not assume a particular time is guaranteed on every device.
- Set a foreground baseline: Record the time and entry count after a successful manual update. Then enable or adjust auto-update so you can tell whether the issue is a failed request or different execution timing.
- Avoid rapid refreshes: Do not repeatedly tap refresh to test auto-update. Repeated requests in a short period may trigger rate limits and change otherwise valid test conditions.
- Allow for system scheduling: Do not assume the app will always get an opportunity to run while the screen is locked, in the background, or when the network changes. Check the actual list and update result after returning to the foreground.
- Know what triggers what: Settings → On Demand establishes a VPN connection based on conditions; it is not a scheduled subscription update switch. Enabling On Demand does not guarantee that the subscription will be fetched every time.
If auto-update fails but a manual update succeeds, compare the network, connection state, and update path at the time of each attempt. If manual updates fail too, return to checking the URL and response rather than shortening the update interval. After recovery, spot-check the address, port, and protocol fields of new entries. A successful subscription update only retrieves configuration; connection availability must be verified separately.
6. Common Questions and What to Include When Reporting an Issue
Why do my existing servers still work when the subscription will not update?
Existing entries store connection parameters already received; an update request accesses the subscription URL. First check in your own account that the URL and token are still valid, then manually update the target subscription once from Home. Do not clear working entries just to test an update.
Why is the list still empty in the app when the URL shows content in a browser?
First check whether the content is a login page, error message, or unsupported export format. A successful browser login does not mean the app’s request includes the same session. Find the subscription URL for Shadowrocket in your account page; do not copy the account page URL from the browser’s address bar.
The entry count dropped after an update. Should I keep refreshing?
First check the target group and filter settings, then check how many entries your account actually provides. Note when the count changed and stop refreshing repeatedly. The provider may have changed the content, or some entries may not have parsed; use the response and error details to tell which.
Can I send someone my full subscription URL to check it?
Do not share the full URL if it contains a token. For troubleshooting, provide a redacted domain, the time of the issue, network type, exact error text, and entry counts before and after the update. If your credentials have been exposed, reset them through your own provider account first, then replace the saved URL in the app.
When contacting your provider, replace “it doesn’t work” with details they can verify, such as: “I manually updated in the foreground over cellular. The response showed 403, and my existing entries remained. I got the same result on Wi-Fi.” If you did not observe a status code, report the exact message instead of guessing. These details help distinguish account, network, and content-format issues, and reduce the need to repeatedly request sensitive URLs.
Verify the Official Shadowrocket App and Learn How to Use It
Shadowrocket is a closed-source commercial app for Apple platforms, primarily iPhone and iPad. The only way to get it is through the App Store. Verify the developer, Shadow Launch Technology Limited, and app ID 932747118. Check the App Store listing for system requirements and purchase availability. A one-time purchase of the app is not a service plan; check your subscription status with your own provider.