If a VPN app cannot download its server list, first determine whether it failed to send the request, establish DNS or TLS, receive an acceptable HTTP response, validate the catalog, or save the result. Do not treat an empty list as proof that every VPN server is offline. The catalog normally belongs to a control-plane path that can fail before any tunnel connection is attempted.

The complete VPN guide explains the service as a whole, while VPN bootstrap provides the stage map. This guide stays with one narrow symptom: the app cannot retrieve or accept the whole catalog.

Key Takeaways

Separate an entirely unavailable catalog from one country or city missing inside a valid list.

Record the timestamp, network, app version, status code, and exact error before clearing state.

A TLS alert, HTTP error, invalid document, and stale cache require different fixes.

Test one trusted alternate network before deleting profiles or reinstalling.

Never bypass certificate checks or send session tokens in a support ticket.

When a VPN app cannot download its server list, is the whole list unavailable?

Clear the app's search, favorites, and specialty filters. If some locations remain visible, use the guide for a missing VPN server location; that is a catalog-content or UI-selection question. This article applies when the list is empty, visibly stale with a refresh error, or replaced by a configuration-download failure.

Also distinguish a provider catalog from a manual operating-system profile. A manual profile may contain one endpoint and never display a provider's live location list. Confirm that you are using the expected official client before diagnosing a download feature it may not have.

Observation	Likely stage	Preserve before changes
Refresh action does nothing	Local UI, blocked task, or app state	App version and exact steps
Hostname cannot resolve	DNS or captive network	Resolver error and network name
Certificate or secure-connection error	TLS, time, interception, or trust	Alert text and device time
HTTP 401 or 403	Session or catalog authorization	Status code and masked account
HTTP 429 or 5xx	Rate limit or service condition	Response class and retry guidance
HTTP success but parse error	Schema, compression, truncation, or client version	Response identifier, not secret body
Old list remains after refresh	Cache revalidation or write failure	Last-update time and storage warning

How should you diagnose the failed request?

Follow the stages in order. Stop as soon as the evidence identifies an owner; later resets cannot repair an earlier network or service response.

1. Record the request context

Write down the exact time, time zone, app and operating-system versions, network type, account shown by the app, and the full visible error. Note whether the list has never loaded, stopped updating today, or works on another device.

Do not copy access tokens, cookies, authorization headers, private keys, or a complete diagnostic archive into ordinary notes. If official support requests logs, use its authenticated channel and review the package for secrets.

2. Confirm the request is actually attempted

Use the app's documented refresh action once. Wait for its stated timeout or visible result; repeated tapping can create overlapping requests or rate limits. If the app is offline by design, paused by the operating system, or denied network access, correct that local condition before testing remote services.

An app crash, frozen task, or immediate local validation error means there may be no outbound request. Restarting the official app once is a reasonable bounded check. Reinstallation is not yet justified.

3. Separate DNS from transport and TLS

A DNS error means the app did not obtain an address through the tested resolver. A connection timeout means an address may exist but the transport did not complete. A TLS alert means the peer processed enough of the secure negotiation to reject or abort it; it is not the same as silence. RFC 9846 defines alerts and handshake termination as explicit TLS outcomes.［2］

Verify the device clock and automatic time setting because certificate validity and some authenticated requests depend on time. Do not fix a certificate error by disabling validation, installing an unknown root certificate, or accepting a mismatched hostname.

4. Interpret the HTTP result precisely

HTTP status codes describe the result of the specific request. A 2xx response indicates that request was received and accepted; 4xx indicates a client-side or authorization condition; 5xx indicates the server failed to fulfill an apparently valid request.［1］ Record the actual code rather than translating every result into “server down.”

A 401 can mean the catalog request lacks acceptable credentials even while the app UI still displays a user. A 403 can mean the identity is known but not allowed for that resource. A 429 requires respecting the service's retry guidance, not a refresh loop. Redirects may indicate an expected service route or an unexpected captive/sign-in path; rely on provider diagnostics rather than entering credentials into an unfamiliar page.

5. Validate the catalog response stage

An HTTP success does not prove the app received a complete, compatible catalog. The body can be truncated, use an unsupported schema version, fail decompression, omit required fields, or contain a signature or identity the client rejects. Preserve the provider's request or response identifier when available, but do not publish the catalog or credentials.

Compare the app version with the official current release channel. If one supported device accepts the response and an older device rejects it at the same time, compatibility is more likely than a global outage. Do not edit a downloaded catalog or import an unverified copy from another user.

6. Check cache and storage only after the response path

HTTP caches can reuse stored responses under defined freshness and validation rules.［3］ The app may also maintain a private catalog database outside HTTP caching. A refresh can succeed remotely yet fail to replace local state because storage is full, the database is read-only, or a write is interrupted.

Record the last successful update time. Use an in-app cache refresh or documented repair action before deleting all application data. Preserve account recovery and any manual profiles first, because a storage reset can remove more than the catalog.

What can an alternate network prove?

One trusted alternate network is a useful comparison. If the same app, account, and version retrieves the list over mobile data but not the original Wi-Fi, the difference lies in the network path, resolver, captive state, proxy, or policy. It does not by itself identify which one.

If both networks fail with the same authenticated HTTP status or response-validation error, preserve that common evidence and check official provider status or support. If another device on the original network succeeds, compare app version, account, time, and local security software instead of blaming the router immediately.

In AethoVPN, a healthy catalog shows each server location with a load indicator, so an empty or stale list is easy to recognise. Compare the same app on the alternate network first; if the list loads there, the original network is the likelier cause. If it fails everywhere, reinstall only from the official downloads page, using the Windows .exe, Linux .deb or Android APK, continue again with your email code, and note whether the error text changes. A working account page is only an account-access observation and does not prove the catalog request has a valid session, correct authorization or a usable response, so keep those stages separate before clearing local state. Download the current AethoVPN build for your device.

When should you clear state or reinstall?

Use destructive steps only after you have identified a local persistence or compatibility problem, preserved recovery details, and exhausted documented refresh and update paths. Sign out only if you know the original login method and can complete multi-factor authentication. Export a manual profile only through a supported secure method.

Reinstalling may help when the official client is corrupted or cannot migrate its local catalog database. It cannot fix an HTTP authorization decision, a provider service failure, or a network that prevents the request from completing. Change one variable, retest, and record the result.

When should you contact support?

Contact the network administrator when the failure is confined to a managed network and policy may control the request. Contact the provider when multiple trusted networks produce the same catalog authorization, service, or response-validation error. Contact device support when storage, secure time, or operating-system network permission fails outside the VPN app too.

Send a compact evidence package: timestamp and time zone, app and OS versions, affected network types, exact error, HTTP status or request identifier if safely visible, last successful update, and the bounded comparisons you performed. Redact account identifiers and secrets.

Summary

Confirm that the entire catalog is unavailable rather than one filtered location.
Diagnose request creation, DNS, TLS, HTTP, response validation, and cache in order.
Preserve precise errors and identifiers before resetting local state.
Use one trusted alternate network and one supported device comparison.
Never weaken certificate checks or import an unverified server list.

FAQ

Does an empty server list mean every VPN server is down?

No. The app may have failed to retrieve, validate, or save the catalog before attempting any server connection. Test the catalog path separately from tunnel endpoints.

Why can I log in but still receive a 401 for the catalog?

The visible user session and the credential attached to a catalog request can have different lifetime, scope, or refresh state. Preserve the status and use the official reauthentication flow rather than editing tokens.

Should I change DNS when the list will not load?

Only when evidence indicates a resolution failure or a controlled comparison supports it. Changing DNS cannot repair an HTTP authorization error, incompatible catalog schema, or local storage failure.

Can a VPN website load while the server list fails?

Yes. The public website and catalog API can use different hosts, credentials, policies, and response formats. Success on one HTTP resource does not prove success on another.［1］

Is clearing the app cache safe?

It depends on the app. A cache action may be narrow, while clearing all data can remove sessions and profiles. Preserve recovery details and follow the provider's documented scope first.

Why does the old list remain after a successful refresh?

The response may have been revalidated but not installed, or the app may be using another private database. Storage errors, interrupted writes, and version incompatibility are possible owners.

What evidence is most useful to support?

Provide the timestamp, versions, network comparison, exact error, safe request identifier, and last successful update. Never include passwords, tokens, cookies, private keys, or recovery codes.

Disclaimer: This guide provides general technical information. Catalog endpoints, authentication scopes, cache controls, and reset behavior vary by provider and client.

Sources:

RFC Editor - RFC 9110: HTTP Semantics — https://www.rfc-editor.org/rfc/rfc9110
RFC Editor - RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 — https://www.rfc-editor.org/rfc/rfc9846
RFC Editor - RFC 9111: HTTP Caching — https://www.rfc-editor.org/rfc/rfc9111

Sources checked 12 September 2026.

Related articles:

VPN App Cannot Download Its Server List: What to Check