EyVPN VPN Troubleshooting Guide

Establish a baseline: identify the affected layer first

Turn vague descriptions into verifiable symptoms

“The network is bad” is not enough to diagnose the issue. Before troubleshooting, disconnect EyVPN and confirm that the current network can open commonly used local websites. Check whether only the browser is affected or all networked programs on the system. If the ordinary network itself is unavailable, fix the router, Wi-Fi, wired connection or ISP access first; changing an EyVPN route cannot restore an underlying outage. Once the ordinary network is working, open the client and check whether the subscription list appears, routes can be selected, the status changes from connecting to connected, and domains resolve and target services open after connection.

Describe symptoms as “which platform, which type of network, what action, and what result.” For example, “The Windows client shows routes after importing the subscription, but every route remains on Connecting” is more useful than “Windows does not work.” Likewise, “The browser works, but one desktop app always times out” suggests that the tunnel and basic network are probably working; focus on app routing, how the app reads the system proxy, or its own cache instead of reinstalling the client.

Build a minimal test environment

During troubleshooting, temporarily disable other tools that alter network paths, including another proxy client, built-in system tunnels, independent browser proxy extensions, network filters and duplicate DNS configurations. The goal is not to disable them permanently, but to prevent multiple components from taking over the default route, system proxy or DNS resolution at once. When several network components run together, even an occasional successful connection does not reveal the actual path, and the issue may return after a restart or network change.

Then choose one ordinary website, one target app and one reproducible action as test samples. Change only one variable at a time: keep the client and mode unchanged while switching routes; if there is no difference, restore the original route and switch the connection mode; only then check DNS or the system proxy. After a change, disconnect completely and reconnect so routing and resolution state are rebuilt. If you change the route, mode and DNS together, you will not know which change worked even if the issue disappears.

Keep a rollback point

Before making changes, record the current client name, connection mode, selected route, whether the system proxy is enabled, and the last successful action before the issue appeared. Export the configuration or keep a copy first; if the client supports configuration groups, create a test group instead of overwriting the existing subscription. Keep a simple record of each change, especially system DNS, router rules and in-app proxy settings. If a new setting causes another issue, you can immediately return to a known state instead of troubleshooting among multiple unknown changes.

If the issue occurs only on a specific access network, compare it with another network when possible. The comparison helps determine whether the problem is closer to the device configuration or the current network; it does not prove that a route is permanently stable. If the same device, client and route connect on another network, the account and subscription are usually not fundamentally at fault. If several devices fail on the same network, check the access network, router and upstream restrictions first. Every conclusion should come from a comparison where only one condition changed.

Cannot connect at all and subscription update failures

Distinguish “no routes available” from “the route cannot establish a connection”

If the client shows no routes after opening, the issue usually occurred while retrieving or parsing the subscription. If routes are visible but selecting one results in endless waiting, an immediate disconnect or a handshake error, the subscription has been read and the problem is in connection establishment. Handle these cases separately. When the list is empty, first confirm that you are using the currently valid subscription entry from the user panel rather than an old manually saved text, a truncated address from a screenshot or browser history. If the client supports subscription updates, trigger the update from subscription management and check whether the error indicates a failed network request, an unrecognized format or denied permission.

Subscription examples in the guide are for understanding the format only, not for actual use. For documentation or testing, keep an obviously fake value such as:

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

When copying the real subscription entry, copy it in full from beginning to end without surrounding spaces, line breaks or Chinese punctuation. Long addresses may be folded or truncated when passed through chat tools, so copy them again from the user panel. A subscription is account-delivery information and should not appear in public screenshots, public documents or ticket titles. When support needs to verify it, provide only the update time and error message; do not paste the full address in a public area.

Self-check order for failed subscription requests

First use a regular browser to confirm that the user panel opens and the current login session is valid. If the panel itself is inaccessible, resolve the local network or browser issue first. If the panel works but the client update fails, fully quit and reopen the client, then run the subscription update again. Some clients retain a failed request or unfinished parsing task; returning to the main screen alone may not clear the state. If it still fails, delete the subscription entry and import it again from the panel, but do not delete an old configuration that still works before keeping a rollback option.

If the error points to a certificate, time or secure connection, check the system date, time zone and automatic time synchronization. A significantly incorrect system clock can prevent secure connections from being verified, even if a browser occasionally opens a page. If the error points to permission or file writing, check whether the client can save its configuration, whether the installation directory is read-only, and whether security software treats the update as an unauthorized change. The key evidence is the exact error and the stage at which it occurs, not the vague statement “the subscription expired.”

Routes are listed, but the connection never establishes

First test another route in the same region, then try a nearby region. If only one route fails, visit the global routes page to review route types and temporarily choose an alternative. If every route fails, return to the local network stack. Fully quit other proxy or tunnel tools, make sure no stale sessions remain, and restart the EyVPN client. After sleep, a network change or an abnormal client exit, an old virtual network interface may retain route state. A complete exit and reconnect is more effective than repeatedly clicking the button.

Next check whether the current network requires web authentication first. Public networks often show a sign-in page during initial access; if the system immediately attempts to establish an encrypted connection, that page may not appear. Disconnect EyVPN, open a regular website in the browser, complete the network provider’s access steps, and then reconnect in the client. Company or campus networks may also restrict certain connection methods. In that case, switch to a compatibility mode already offered by the client, but do not enter server parameters from unknown sources.

Isolate the configuration before reinstalling

Reinstalling is not the first choice because uninstallers may leave system proxy settings, virtual interfaces and user-directory configuration behind; a direct reinstall may also bring the old problem back. A safer approach is to export a working configuration, quit the client, create a blank configuration or use its reset function, and test with only the current subscription. If the blank environment connects, the issue comes from old rules or local overrides. If it still fails, consider uninstalling and reinstalling through the quick-start guide.

After reinstalling, do not restore every custom rule at once. First use the default settings to verify subscription updates and basic connectivity, then restore routing, startup and DNS settings one by one. If the issue returns after restoring one item, you have found a reproducible condition. Include that condition in the ticket so support can assess a configuration conflict instead of repeating basic network checks.

The client says Connected, but websites do not open: routing and DNS issues

First determine whether DNS resolution failed or all traffic is blocked

A Connected status only means that the tunnel process is running; it does not mean every type of request is passing correctly. If the browser says it cannot find a domain, the name cannot be resolved or there is a DNS error, focus on DNS resolution. If it reports a timeout, a reset connection or prolonged waiting across all apps, also check the default route and system proxy. Compare a page opened previously with a brand-new page, but do not use a cached page alone as proof that the network works.

After opening a command line, use a public domain that contains no account information to check resolution. Choose the corresponding command for your platform:

nslookup example.com

ipconfig /flushdns

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

resolvectl flush-caches

nslookup returns a result but the browser still cannot open the page, so DNS is not the only possible cause. Continue checking the system proxy, default route and browser settings. If the command returns nothing or repeatedly times out, clear the system DNS cache, disconnect and reconnect, then run the same test again. Resolution services differ across Linux distributions. If the command is unavailable, use the distribution’s built-in network manager to refresh the connection rather than installing a repair script from an unknown source.

Clear stale system proxy state

After an abnormal client exit, system sleep or forced process termination, the system proxy may still point to a local interface that is no longer listening. Programs that rely on the system proxy then try to connect to a nonexistent local service, appearing as “websites fail after connecting, and still fail after disconnecting.” Fully quit the client first, then check whether the proxy switch remains enabled in the operating system’s network settings. If the client provides “restore system proxy” or “clear proxy,” use the built-in action first. Once the system proxy is restored, reopen the client and connect again.

The browser may also have its own proxy extension or use secure DNS separately from the system. Temporarily disable the independent browser proxy so the browser follows the system network. If access works, check whether the extension rules conflict with the client. Restore secure DNS to follow the system during testing as well, because sending domain requests through a separate resolution path can make browser results differ from other apps. Restore the original settings after diagnosis if needed, but avoid letting multiple components control the same function.

Check split-routing mode and the default route

Rule mode chooses a traffic path based on domains, addresses or apps; global mode is useful for checking whether a rule was missed. If the basic connection is established but only certain websites are inaccessible, temporarily test the global connection mode offered by the client. If global mode restores access, the route itself works and the issue is more likely a rule match or DNS result that did not enter the expected rule. If global mode also fails, continue checking the route, system routing and target service. Restore the mode that fits everyday use after testing; global mode should not become a permanent answer to every issue.

Multiple network adapters can easily create default-route conflicts. When a device is connected to wired, wireless, virtual or shared networks at the same time, the system may choose a different exit after a network change. Keep the connection method actually in use, temporarily disconnect other networks, and rebuild the EyVPN connection. If the issue disappears after removing an extra network, check system network priority and sharing settings instead of continually changing remote routes.

Limits of DNS troubleshooting

Do not attribute every website issue to DNS or repeatedly stack custom resolver addresses. DNS converts domain names into network addresses, but it cannot fix an expired subscription, a failed route handshake, an incorrect system proxy or a target service refusing the connection. Change DNS only when the error, command output and comparison tests all point to resolution. After changing it, clear the cache and reconnect; otherwise the system or browser may reuse the old result.

If only one domain is affected while other websites and apps work on the same route, first try a different region and clear that domain’s browser cache. The target service may return different addresses by exit region or temporarily reject the current session. Keep only the domain, time, route region and error message for support; do not submit browsing history or unrelated private information.

Layered diagnosis for slow speeds and peak-hour slowdowns

First identify whether the delay affects downloads, initial page load or real-time interaction

“Slow” can describe several different experiences: a long wait for the first page render, low sustained speed for large files, fast video startup followed by buffering, or noticeable latency in voice and remote control. These have different bottlenecks. Initial loading often depends on DNS, connection setup and the number of page resources. Sustained transfers depend more on local bandwidth, route path and target-server limits. Video buffering is also affected by content-distribution region and quality policies, while real-time interaction depends more on round-trip path and jitter. Identify the slow operation before choosing a meaningful comparison.

During testing, pause other programs that are syncing, updating or uploading so background tasks do not consume local bandwidth. Confirm that the access network is stable with EyVPN disconnected, then connect to a nearby route and compare using the same app, content and roughly the same time. Do not compare downloads from different websites directly because target services have different routes and rate limits. Do not conclude from one brief test either; short tasks are easily affected by caching and connection warm-up.

Choose nearby routes first, then adjust for the target region

For everyday browsing and real-time interaction, start with a geographically nearby route to reduce uncertainty between the local network and the entry point. When content from a specific region is needed, choose the corresponding exit region. EyVPN covers 100+ countries / 180+ routes, and one region may offer different route types and paths. Review regional and route details on the global routes page, but do not judge performance by country name alone. The actual path also depends on the ISP, access network and time of day, so keep one stable everyday route and a nearby or same-region alternative.

When switching routes, disconnect completely and reconnect, then reopen the target app or start a new browser session. Some apps reuse long-lived connections, so an old session may remain on the previous path even after the client changes routes. If you only click switch without restarting the target app, the test may mix two paths. Video services may also retain region and quality caches; exit the playback page and enter it again instead of only moving the timeline.

For peak-hour slowdowns, check whether they occur only on the current access network

Slowdowns during busy evening hours should not automatically be blamed on a remote route. The home broadband exit, wireless conditions, regional ISP interconnection, remote route and target service may all change at once. First check whether ordinary browsing with EyVPN disconnected also shows slower page responses, video buffering or packet-loss symptoms. If the basic network also worsens, address local wireless interference, router load or upstream access first. If the basic network is stable but several remote routes slow down together, compare different regions and route types.

When troubleshooting Wi-Fi, move closer to the access point, pause bandwidth-heavy tasks and compare with a wired connection when possible. A strong-looking signal can still suffer retransmissions from interference; these may be subtle on ordinary webpages but become obvious in live video and remote control. If wired access is stable while Wi-Fi stutters, changing EyVPN routes will not fix the root cause. Conversely, if only a specific route has issues at peak time on the same access method, temporarily switch to an alternative and record the region, route name and time.

Protocol, system load and transport behavior

When the client offers different connection methods, switch to a compatibility option only after the default settings fail to suit the current network. Record the original setting first and rebuild the session after changing it. Some networks handle persistent connections well, while others are more likely to interrupt them during roaming, frequent switching or shared access. No option is optimal for every network condition. If the client does not expose an advanced setting, do not copy unknown configuration from unofficial guides; it may create an unsupported state.

The device’s processing load also affects encrypted traffic. System updates, a busy disk, power-saving limits on background activity or many high-load browser tabs can reduce network performance. Check Task Manager or the system activity monitor, close unusually demanding programs and test the same route again. If only one device is slow while another supported platform on the same network works, focus on the device OS, client configuration or app environment. If every device slows down on the same access network, check the network and routes first.

Separate checks for video and large-file transfers

If video opens but keeps buffering, set playback quality to Auto so the service can adapt to current throughput, then observe connection stability. If low quality is stable but high quality keeps buffering, sustained throughput is insufficient. If every quality level stops at a similar point, the issue may involve the session, app cache or target-service connection. Try another route in the same region and restart the app. For route and region guidance, see the Streaming guide.

For large downloads, consider limits imposed by the download source itself. If only one of several sources is slow on the same route, that does not usually prove a route-wide issue. Compare the same source with EyVPN disconnected and connected, and note whether the transfer remains stable after it starts rather than focusing only on the momentary peak. When contacting support, provide the service category, route region, access-network type and symptoms; do not include private filenames or account content.

Frequent disconnects and mobile background dropouts

First determine whether the tunnel disconnected or only the app session expired

An app message saying “connection lost” does not necessarily mean the EyVPN tunnel ended. Return to the client and check its status. If it still says Connected and other websites work, the issue may be the target app’s login session, long-lived connection or reconnect after a region change. Only investigate a tunnel dropout when the client itself shows Disconnected. Also note whether the dropout always occurs after locking the screen, switching between Wi-Fi and mobile data, device sleep, signal changes or sending the app to the background. These triggers are more useful than the dropout alone.

Random disconnects during continuous use and disconnects after a network change should be handled separately. The former may involve access-network jitter, system resources, route status or the client process; the latter usually involves a changed default route, rebuilt network extensions or background permissions. Record the last action before the dropout, such as closing the lid, locking the screen, leaving Wi-Fi coverage, enabling power saving or switching networks. A reproducible trigger is often easier to locate than an error that appears only after waiting.

Desktop sleep and network-interface changes

After Windows or macOS resumes from sleep, the system may renumber a network interface or obtain a new address while the client retains its pre-sleep connection state. The client may appear connected while websites remain inaccessible, or it may disconnect immediately after resume. Manually disconnect first, wait for the ordinary network to recover, and reconnect. If the issue returns after every sleep, check the client’s auto-connect setting, system network-extension permissions and startup state so the system and client do not both restore old sessions.

When wired and wireless connections are active together, the system may switch the default exit as signal or priority changes. A tunnel built on the old exit may not migrate cleanly. During troubleshooting, keep only the main access method active and restore other networks after stability is confirmed. Linux users should also check that the network manager is not rewriting routes or resolution settings in the background. If manual scripts and the desktop network manager control the same interface, standardize on one management method first.

Mobile background management is a common cause

iOS and Android both manage background tasks, but differently. On iOS, confirm that the system has approved the connection configuration and check whether on-demand rules match the current Wi-Fi conditions. If the connection is configured to activate or deactivate only on certain networks, a changed network name may trigger a disconnect. Temporarily simplify the on-demand conditions and connect manually to confirm that the basic tunnel survives locking and unlocking. Once stable, restore automatic connection conditions one at a time.

On Android, check whether battery optimization, background freezing or the manufacturer’s task manager restricts the client. Allow the client to run in the background and keep its connection notification enabled. Do not run multiple always-on connection services at once because the system generally permits only one primary tunnel to control the network. If the client disconnects as soon as it moves to the background but remains stable in the foreground, focus on background permissions and power-saving policies rather than remote routes.

When switching between mobile data and Wi-Fi, the local address used by the original connection changes. Some clients reconnect automatically, but the target app’s old session may still expire. After switching, wait for the ordinary network to become available and check whether the client reconnects. If the app remains unresponsive, fully close and reopen it. Do not keep clicking Connect before the system has obtained the new network; this can leave multiple failed tasks and lengthen recovery.

Auto-reconnect does not replace root-cause analysis

Auto-reconnect helps with occasional network changes, but if the connection repeatedly comes and goes, it only hides the problem and increases app-session switching. When reconnect loops appear, temporarily disable automatic actions, connect manually and observe the first disconnect error. If the error flashes briefly, use the relevant time range in the client log rather than copying an entire long-term log. Before submitting logs, check for subscription entries, usernames or local file paths and redact unrelated sensitive content.

If the same route is stable on one fixed access network but disconnects frequently on another, the network environment is the key variable. If every route disconnects on one network while another device is stable, check the current device. If only one route disconnects, temporarily switch to another route in the same region and submit the route name and time. Grouped findings like these let support start at the right layer.

A single app bypasses the proxy: check routing and the app network stack

When the browser works, do not start over with the subscription

When the browser and other apps work but one app cannot connect, the subscription, basic route and most system networking are already functioning. Deleting the subscription, reinstalling the client or repeatedly changing accounts usually will not help. First determine whether the target app is completely offline or only certain content fails, then check whether it opened an old connection before startup. Many desktop apps reuse long-lived sessions, so they may keep the old path after the client connects or changes routes. Fully quit the target app and reopen it while EyVPN is connected.

If reopening fixes the issue, it came from the old session and routing rules do not need changing. If the issue remains, use the client’s global connection mode for a temporary comparison. If the app works globally, it likely missed a rule or resolved domains through another path. If it still fails globally, check the app’s own proxy settings, certificate policy, region cache and service status. Global mode is for diagnosis, not a permanent replacement for precise routing when it is unnecessary.

System proxy, virtual adapters and in-app proxies are not equivalent

Some apps follow the operating system proxy, some create direct network connections, and others read proxy parameters only from their own settings page. With only the system proxy enabled, apps that ignore system settings may continue to connect directly. Virtual-adapter mode lets the system route more traffic, but the app’s own network stack and routing rules can still affect it. Before troubleshooting, identify which method the client uses. “The system proxy is enabled” does not prove that every app follows the same path.

If the target app offers proxy settings, check for an old address, port or manual mode. When the client already controls system networking, pointing the app to another local proxy can create duplicate forwarding or connect to a stopped service. During testing, let the app follow system settings or explicitly use the local interface provided by the client, but do not mix multiple sources. Use the fields shown by the current client; do not copy fixed parameters from unknown documentation.

Domain rules, process rules and direct-connection exceptions

Rule mode may choose a path by domain, destination address or process name. After an app update, the process name, helper process or resource domains may change. An old rule may cover only the main program while missing login, images, updates or real-time communication, leaving the interface visible but content incomplete. Record the specific function that fails and check the client’s connection log to see whether the related domain used the expected path. Do not permanently proxy all unknown traffic to hide a missing rule; adjust the relevant rule after confirming the target.

Some apps use an independent DNS path outside the system or preferentially reuse cached network addresses. Even with correct domain rules, a resolution result that bypasses the client may not match them. Fully quit the app, clear its network cache or sign in again, then rebuild the connection. If the client supports process-based rules, use a process comparison; otherwise focus on domains and system routing. Repeat the original failed action after changing settings rather than checking only whether the home screen opens.

Interference from browser extensions and app caches

A desktop app may fail while the browser works because a browser extension provides a separate path. Retest in a browser window without an independent proxy extension and confirm that the browser is actually following EyVPN. Conversely, if only the browser fails, check extensions, browser secure DNS, cache and the user profile instead of changing the whole system first. When comparing different browsers, make sure their proxy and DNS settings match; otherwise the results are not comparable.

A service may also save login state based on the exit region, leading to a false diagnosis. After switching regions, it may require session verification or continue showing cached regional content. Sign out and reopen the app, then sign in through the service’s normal flow. If the issue concerns account region, content authorization or a server-side restriction, route connectivity cannot change the target service’s own account rules. Distinguish a failed network request from an explicit region or account message and provide the exact message in the ticket.

How to report a routing issue effectively

If global mode works but rule mode fails, report the platform, client connection method, target app, failed function and time, along with a redacted connection log. Also state whether the browser works, whether the same app’s web version works, and whether changing the route region changes the result. Support does not need your full browsing history or the target account password. The more the report focuses on the failed request and rule difference, the easier it is to identify a missing rule, an app update or a temporary target-service change.

If only a corporate intranet, organization-specific app or local-device discovery feature fails, first confirm whether those addresses are meant to connect directly. Sending local resources through a remote route can block printing, file sharing, internal domains and LAN management pages. Restore direct-connection rules and test again so external access does not disrupt internal resources.

Account, traffic and device status: identify “device limit” messages

Check the service facts first, then identify where the message comes from

EyVPN plans support unlimited simultaneous devices. If the interface shows a device limit, session conflict or authorization failure, do not assume that the EyVPN plan has a fixed device cap. First identify whether the message comes from the user panel, EyVPN client, operating system or another third-party client. Third-party clients may impose their own limits on configuration count, connection profiles or store accounts, while operating systems may allow only one primary network tunnel at a time. These limits are separate from the simultaneous-device allowance of the EyVPN plan.

The most effective check is to preserve the page and exact text containing the message, then confirm whether the same account connects normally on another device. If other devices work, the issue is usually concentrated in the current device’s client state, system permissions or duplicate connection profiles. If every device shows an account authorization issue, check the plan status, login status and subscription validity. Do not delete working configurations on other devices because of a local message from one client.

Check the difference between monthly plans and traffic packs

Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. The two plan types work differently: monthly plans depend on the current billing cycle, while traffic packs depend on the remaining balance. Check the user panel for the current status and see the plans page for the complete rules.

If the client still shows old routes but actual requests fail, the local configuration may not have updated. Sign in to the user panel to confirm the plan and subscription status, then return to the client and update the subscription. Seeing route names does not prove that current authorization is valid because the client may display cached configuration. If the panel is normal and the subscription updates successfully but the client still reports an authorization issue, submit the exact error and update time so support can check the server-side record.

Login, account creation and subscriptions are separate states

EyVPN accounts require no email address; a username and password are enough. Successful user-panel login confirms only that the credentials work. The plan status determines whether the subscription is available, and a successful subscription import means the configuration has reached the local client. Confirm these stages separately. A common mistake is assuming that a working panel login guarantees a client connection, or that old routes shown by the client prove that the plan status has not changed. Check the panel account, plan status, subscription update time and client result in order rather than reducing them to one “account is fine” conclusion.

If you forget the username or password, use the account process provided in the user panel. Because account creation does not depend on an email address, store the username and password securely. Support does not need your password to troubleshoot a connection and it should never be included in a ticket. When the account must be identified, provide only the non-sensitive identifier visible in the account as requested by the ticket form, allowing support to verify it through the controlled process.

False conflicts caused by duplicate configurations and old sessions

Repeatedly importing a subscription on the same device can create several similarly named configurations. If an old configuration is selected, the panel may be normal and another device may work while the current device keeps failing. Check the configuration source and last-updated time. Keep the current subscription and disable or remove clearly expired duplicates. Before deleting anything, confirm which configuration is in use so you do not remove the only working one.

Operating systems generally allow only one primary tunnel to control the network. If the current device still has another connection service set to always-on, on-demand or auto-start, it may compete for the connection in the background even when no obvious window is open. Open the system network settings and check which connection profiles are actually enabled. During troubleshooting, keep only the EyVPN profile. Re-enable other services later if needed, but do not let them auto-connect under the same conditions.

Handle payment status separately from connection issues

EyVPN supports Alipay, WeChat Pay and USDT. The payment page, order status and client connection are separate stages. If an order is still processing, check the result in the user panel first; repeatedly importing the subscription will not advance the order. If the order is complete but the plan is not shown, submit the information visible on the order page so support can verify it. Redact payment credentials and unrelated transaction details from ticket screenshots, keeping only the order status, time and necessary identifiers.

Create separate tickets for connection issues and payment disputes. The former needs the platform, client, route and error log; the latter needs the plan and order status. Combining both issues in one description makes troubleshooting switch back and forth. If you have just changed plans, refresh the user panel first, then update the client subscription. If the issue remains, state the before-and-after status and the client update time.

Information needed for recovery checks and ticket submission

Confirm that recovery is not an accidental success

After a connection succeeds, do not immediately restore every custom setting. Repeat the action that originally failed and confirm that websites, the target app and subscription updates all work. Then disconnect and reconnect to see whether the result remains consistent. If the issue is related to sleep, screen lock, network switching or evening usage, test again under that condition. Recovery is real only when the connection remains normal across the original trigger; one accidental success proves only that the current session works.

Then restore the browser extensions, in-app proxy, auto-connect, routing rules and custom DNS one at a time. Run the same test after each change. If the issue returns, the last setting restored is a valuable clue. Record its name and purpose instead of stacking on more changes. If everything remains normal, remove temporary configurations created during testing while keeping the current subscription and necessary exported backup.

When to hand the issue to support

Submit a ticket when subscriptions fail to update across multiple supported platforms and access networks, every route returns the same authorization error, the plan or order status in the user panel does not match reality, or the issue is reproducible but the client offers no actionable fix. If one route is temporarily abnormal, switch to an alternative in the same region and report the route name and time; you do not need to wait for every route to fail.

Client crashes, network extensions that cannot start, repeatedly revoked system permissions and persistent log errors are also suitable for support review. However, a system that cannot access the internet at all, a failed router connection, organization-network permissions or a target service’s account restrictions may fall outside EyVPN’s direct control. A ticket can still clarify the boundary, but describe the ordinary network and other apps accurately instead of labeling every symptom a route failure.

What an actionable ticket should include

Write the symptom and platform directly in the ticket title, such as “macOS cannot resolve domains after connecting” or “Android disconnects after moving to the background.” Do not use only “urgent,” “doesn’t work” or “network issue.” In the body, state when the issue began and whether it worked before, followed by the access-network type, client name, connection mode, route region, exact error and self-checks completed. If you changed routes or networks, say which combinations worked and which failed.

Screenshots should show the error and necessary interface, but redact usernames, the full subscription entry, payment credentials and unrelated content. Include only the relevant log section around the failure rather than the entire long-term record. Redact local file paths, subscription information or target-account content before uploading. Support does not need your password or browsing history unrelated to the issue.

Symptom:
Platform:
Client and connection mode:
Access network type:
Selected route region:
Exact error message:
Issue start time:
Can the issue be reproduced consistently:
Self-checks completed:
Result after changing routes:
Result after changing the access network:
Available screenshots or redacted logs:

Use comparison results instead of guesses

“It may be a route issue” is less useful than “The same device works on another access network, but every route fails to establish a connection on the current network.” “It may be DNS” is less useful than “Domain lookup failed and recovered after clearing the resolution cache, while direct access remained normal.” “One app does not work” is less useful than “The browser and other apps work, global mode works, but the login API times out in rule mode.” Clear comparisons let support skip verified steps and focus on the most likely layer.

If the issue occurs only during a certain period, record the local time, route region and exact action; do not infer the congestion point from one speed test. If it affects only one target service, include the service name, website or app, failed function and exact error, but never submit the target account password. If only one regional route is affected, say whether an alternative in the same region works. A clearer structure means fewer follow-up questions.

Organize the configuration after recovery

After the issue is resolved, remove invalid duplicate subscriptions, disable unused system tunnels and keep the stable configuration as the everyday setup. Organize frequently used routes by region and purpose, but do not mistake a temporary test route for a permanently optimal choice. Network conditions change with the access location and target service. If similar symptoms appear later, return to the baseline instead of mechanically repeating every previous change.

If you changed system DNS, the browser proxy, an in-app proxy or background permissions during troubleshooting, confirm that the settings fit everyday use. Restore test-only global mode to the original routing mode, and re-enable security software or system protection that was disabled for diagnosis according to the original policy. The final state should have clear ownership, one connection component, a current subscription and system proxy behavior that starts and stops correctly with the client.

Further reading and routine maintenance

If initial setup is still unfamiliar, return to the quick-start guide to review the import and verification steps. Windows users can read the complete Windows VPN beginner’s guide, Android users can read Android VPN from scratch, and iOS users can see recommended iOS VPNs and client testing for store-region and client choices. Those articles cover platform-specific operations; this page remains an index from symptoms to causes.

For everyday use, keep one verified client configuration and avoid importing rules from unknown sources. When an issue appears, record the symptoms first and then compare one variable at a time. Route changes, system updates and network changes can all alter connection conditions, but following the order “ordinary network, subscription, tunnel, DNS, routing, target app” usually narrows the issue to a specific layer instead of leaving it as a vague, unreproducible description.