For users with an existing provider and subscription who can’t import it, see an empty list after updating, or still see old entries. Keep existing entries for now, then check for a URL error, a failed request, an incompatible response, or a display issue—in that order. Change one thing at a time and use the original error message to guide your next step. A failed connection test does not necessarily mean the subscription failed to parse.
1. Distinguish subscription requests, parsing, and connection tests
Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad, and available exclusively through the App Store as a one-time purchase. Buying the app does not include a service plan. This guide assumes you already have a subscription. This site does not provide, sell, or recommend servers, subscriptions, or providers. Check the App Store listing for pricing, system requirements, and general purchase availability.
“Subscription updated successfully” and “server connects” are two different things. An update first requests the subscription URL, then parses the response for entries. Server connections, authentication, and traffic forwarding only come into play once recognizable entries have been imported. If the list is empty, changing a server’s port or protocol usually doesn’t address the part that failed.
- Request did not complete: You may see a timeout, a DNS lookup failure, or a certificate error. Start by checking the network path.
- Response could not be parsed: The request returned content, but it may be a login page, a verification page, or a subscription format the app can’t parse.
- No usable entries: The response may genuinely be empty, or entries may be hidden in a collapsed group, filtered by a search, or replaced by the update.
- Entries are present, but tests fail: The subscription import produced entries. Check the connection settings for those servers instead of importing the subscription again.
2. Check the full subscription URL without changing its credentials
Go to your provider’s account page and copy the subscription URL provided for Shadowrocket again. Don’t reconstruct it from a truncated chat preview, text recognized from a screenshot, or the account page’s address bar. Subscription URLs often contain authentication parameters; even one missing character can send a different request.
https://example.com/sub?token=xxxxThe values below are placeholders and cannot be used as a real subscription. They illustrate the structure: the scheme is https, the hostname is example.com, the path is /sub, and the query includes a token parameter. Your provider determines the actual path and parameters; they don’t need to match this example.
- Check the beginning and end: Remove any accidentally copied spaces, line breaks, quotation marks, or punctuation. Don’t remove symbols that are part of the URL.
- Check the parameters: Make sure no values are missing after
?,&, or=. Don’t decode and rebuild strings containing%. - Check the URL’s purpose: An account login page, purchase history page, and subscription URL are different. A link for sharing a single server is not a subscription URL that can be regularly updated.
- Check whether the credentials were reset: If you reset your subscription credentials in your account, the old URL may stop working immediately. Use the newly copied URL.
- Keep track of the source: In Home, find the edit option for the subscription and check its saved URL. Note its group and the number of existing entries before saving changes. This helps avoid adding several subscriptions with the same name.
3. Tell network failures apart from server rejections
After one update attempt, note the full message before deciding whether to check the network or your account. The following standard HTTP status lines may appear in a response, log, or diagnostic result; they won’t necessarily appear verbatim in every Shadowrocket screen. Base your assessment on the record for the request you just made.
Error: 401 Unauthorized
Cause: The server didn’t accept the authentication details in the request; the credentials may have expired. What to do: Check your subscription access in your account and copy the URL again. Don’t guess at a working value by repeatedly changing the token.
Error: 403 Forbidden
Cause: The server denied access, possibly because of permissions, an access policy, or a restriction on the request’s origin. What to do: Note when it happened and which network you used, then ask your provider about the restriction. A 403 alone doesn’t prove that your account has expired.
Error: 404 Not Found
Cause: The requested path wasn’t found. The URL may be truncated, the endpoint may have changed, or the server may use this status to hide an invalid resource. What to do: Get the full subscription URL from your account page and check the saved URL. Don’t guess at the missing path.
Error: 429 Too Many Requests
Cause: The server considers the requests too frequent. What to do: Stop refreshing repeatedly. If the response includes Retry-After, wait for the specified time; otherwise, follow your provider’s instructions before trying again.
With a request timeout or DNS lookup error, the server may not have received the request. First check whether the current Wi-Fi network requires you to sign in through a web page. If available, try cellular data once for comparison. For a certificate error, check the device’s date and time, network authentication status, and the server certificate. Don’t hide the issue by disabling certificate verification.
Bottom line: Check permissions first when you receive a rejection
If you received a response such as 401 or 403, first check subscription access and the server’s access requirements. If there was no response, start with the network path. Don’t treat both cases as a reason to change server protocols.
4. Check whether the response can be parsed
A successful HTTP request only means a response was received; it doesn’t guarantee that the response is a valid subscription. A server can return 200 with a login page, an interactive verification page, a maintenance notice, or an empty response. Opening a URL in a browser also doesn’t mean Shadowrocket can read server entries from it: the browser may already be signed in, while the app’s subscription request has no such session.
| What you see | What it means | What to do next |
|---|---|---|
| A login or verification page is returned | The response is a web page, not subscription content the app can parse directly | Use the dedicated subscription URL and ask your provider to check the endpoint response |
| An empty response is returned | This response contains no body to parse | Check your account’s subscription status, visible entries, and the content generated by the server |
| A response body is present, but nothing can be parsed | The format may be incompatible, the content may be truncated, or data fields may be missing | Use a subscription format explicitly supported by Shadowrocket and keep a redacted copy of the error details |
| Only some entries appear | Some records may be invalid, or the current view may not show all results | Clear search filters, expand the group, and compare the results with the entries the server should return |
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocol names; their presence alone doesn’t prove that the subscription text is valid. It doesn’t confirm that each record has complete authentication fields, an address, a port, and transport parameters. Don’t bulk-change protocol names, guess at port numbers, or paste webpage source code as server entries just to make the import appear successful.
- If your account page offers multiple formats, choose the one explicitly marked for Shadowrocket. Don’t judge compatibility by the file extension alone.
- If only some entries import, tell your provider which entries are missing. Don’t share the full subscription contents publicly.
- If the server returns unexpected content, refreshing repeatedly in the app won’t fix the data generated by the server.
5. Check Home for display issues and update timing
In Home, clear any search, expand the subscription group, and confirm you’re looking at the intended subscription—not another group with the same name. Note the number of entries before updating and whether any old entries still work. If an update fails but the old list remains, that doesn’t mean you have the latest content. If the list suddenly becomes empty, that alone doesn’t prove the app deleted valid data.
- Preserve the current state: Note the group name, the number of entries before updating, the error message, and when you tried. Don’t delete the whole group or reinstall the app first.
- Update just one subscription: In Home, find the update action for the intended subscription and run it once manually. If menus vary by layout, use the update option shown for that subscription.
- Wait for the result: Let the request finish before checking. Don’t trigger updates repeatedly or combine results from updating several groups at once.
- Check the network path: If the app can update subscriptions through a proxy, first confirm that the current connection works. Trying to fetch a subscription through a server that only appears in the empty list creates a deadlock.
- Restore your usual settings: If you paused automatic updates or changed the network path during troubleshooting, restore them after confirming the fix. Note what worked so the next automatic update doesn’t fail for the same reason.
Config, Proxy, Direct, and Scene in Global Routing control how traffic is handled; they don’t convert subscription formats. Whether a subscription request goes through a proxy also depends on the app’s update settings and the current network path. Switching to Proxy alone doesn’t guarantee that updates use a proxy. Settings → On Demand triggers connections based on conditions; it won’t fix an invalid URL or an incompatible response.
Bottom line: Keep working entries until you’ve verified the update
Fix the subscription request or response first, then check whether the entries return. Don’t delete working entries to test updates; you could lose both a useful comparison and a working connection path.
6. Common questions and what to include in a report
If you still can’t find the cause, one complete record of a failed attempt is more useful than repeated retries. Narrow the problem down to one stage—URL, request, response, parsing, or display—to avoid repeating checks or misdirecting an account access issue to connection settings.
The subscription opens in a browser. Why can’t the app parse it?
First check that the browser shows subscription content, not a login or verification page. The browser may be signed in already. Copy the dedicated subscription URL again from your account page, then ask your provider to check the response to a request made without a login session.
The list has entries, but they all time out. Should I import the subscription again?
Keep the subscription and test the existing entries’ connections in Home. Check the server status and authentication details. Visible entries mean that at least some content was parsed; a connection timeout doesn’t prove the subscription URL is wrong.
The list became empty right after an update. Can I keep refreshing?
Stop retrying for now. Clear search filters, expand the group, and check whether your account page should show entries. If the server really returned an empty response or a 429, address the content issue or wait for the limit to lift instead of continuing to refresh.
It worked on a different network. Do I need to change every server?
Don’t start by changing all the servers. Note which network worked and which didn’t, whether you used a proxy, and the error message. Focus on DNS resolution for the subscription domain, network authentication, and request access restrictions. Server settings and subscription requests are separate things to check.
What to include when contacting your provider
- When it happened: Include the date, time, and time zone so the provider can check its request logs.
- Where you were in the app: Say whether this was the first import or an update to an existing subscription in Home, and note the number of entries before and after the issue.
- Original error: Include the full error text or status code, not just “it doesn’t work.” Redact credentials, QR codes, and personal information in screenshots.
- Comparison results: Note whether Wi-Fi and cellular data behaved differently, whether only one existing subscription failed, and whether you changed the update path.
- App environment: Provide the device, OS, and version information shown in the app. Don’t guess the version or clear local settings before troubleshooting.
You’ve resolved the issue when the intended subscription request completes, its response parses, and Home shows the expected entries; then test server connections separately. Don’t treat a vanished error message as proof that everything is fixed, or assume that one successful update means every connection will work later.