VPN Troubleshooting Manual

DIAGNOSIS BASELINE

Establish a troubleshooting baseline: separate the layers before reinstalling

Write down exactly “what is broken” first

Most troubleshooting fails not because tools are missing, but because the problem description is too broad. “It doesn’t work” could mean the client will not start, the subscription will not update, a route handshake fails, the connection succeeds but domains cannot resolve, the browser works while one app does not, or the target website is temporarily unavailable. Before doing anything, record the symptom in one complete sentence: platform, network type, route region, client status, affected pages or apps, and whether access returns when the proxy is off. Once this is clear, the next steps are usually much shorter.

Break the problem into five layers: device and system, current access network, client and subscription, selected route, and target website or app. Change only one layer at a time. For example, keep the device and network unchanged while switching to another route in the same region; then keep the route unchanged while testing another access network. If you reinstall the client, switch routes, change DNS and edit routing rules simultaneously, even a successful result will not reveal the real cause, and the next incident will bring the same guesswork back.

Cross-check results instead of relying on impressions

The most useful baseline is a comparison using the same account with different variables. First check whether ordinary websites open with the proxy disabled. If they do not, the problem is on the local network, and changing routes will not help. If they work with the proxy off but no websites open after connecting, check proxy mode, system-proxy takeover and DNS. If only one target is unreachable, first check the target service status, regional requirements, cache and app routing rather than immediately blaming the route.

Next determine whether the issue affects one device or every device. WeekVPN supports Windows, macOS, iOS, Android and Linux, with no device-count limit. If only one device fails on the same network, focus on client permissions, system time, leftover proxy settings, security software and routing rules. If several devices fail on the same network but recover on another access network, focus on the current network environment. Only when the issue reproduces across different devices, networks and routes is it worth organizing evidence and submitting a ticket.

Preserve the original state and a rollback point

Before clearing any configuration, note the current client name, selected route, proxy mode, subscription update time and exact error text. A subscription URL is an account credential; never include it in public screenshots or discussions. When showing the subscription update screen, hide the full URL, access token and QR code. If you use a manual configuration, copy the original file before changing rules; if you use the system proxy, record its original setting. This is not about adding steps—it ensures every change can be undone.

Do not make “reinstall” the first step. Reinstalling only clears some client state; it cannot fix the access network, account validity, regional restrictions on the target service or the DNS path. It may also remove valuable logs and reproduction conditions. A better order is: fully quit and reopen the client, update the subscription, switch to another route in the same region, check the system proxy, then clean up leftovers according to the platform. Reinstall only when the client itself will not start, its configuration database is corrupted or system permissions are clearly abnormal.

By the end of this chapter, you should have a clear conclusion: whether the issue is limited to one device, one network, one route, one domain or one app. The following chapters use that boundary as their starting point. If you still cannot classify it, return to the simplest test environment: disable extra routing rules, choose a standard route, use only a browser to open an ordinary webpage, then restore the original settings one by one. A stable baseline is more valuable than a complicated test.

CONNECTION FAILURE

Cannot connect at all: from client status to route handshake

Distinguish a client that has not taken over traffic from a failed route connection

No visible status change after clicking Connect is usually a different problem from a clear failure message. For the former, first check that the client is running, the system allows a network interface to be created, background services are active and a configuration is selected. The latter is more likely related to the subscription, route or access network. Do not look only at the color of the connection button; check for explicit text such as “Connected,” “Timed out,” “Authentication failed,” “Invalid configuration” or “Unable to resolve.” Preserve the exact error because similar symptoms can originate at completely different layers.

Fully quit the client rather than simply closing its window. On desktop systems, the program may remain in the menu bar or notification area; on mobile, leaving the screen does not necessarily stop the tunnel. Confirm that the process has ended, restart it and select the subscription configuration you just updated. If the client requests network permission, confirm in system settings that the permission is still valid. After a system upgrade, configuration migration or security-policy change, existing permissions may need to be confirmed again.

Check the basic network and system time

With the proxy disabled, open an ordinary webpage to confirm that the current network has basic connectivity. If the browser shows an access-authentication page, complete the public network’s authentication before starting the client. Some office, campus and public networks restrict unfamiliar connection methods; use another access network for comparison. The comparison is decisive: if the same device recovers immediately on another network, the client and account are probably fine, so focus on the original network instead of deleting the subscription.

The system date and time zone should also stay synchronized automatically. Encrypted connections rely on certificate-validity checks, and a significant time error can cause the handshake to fail, appearing as a connection or certificate error. Do not guess the correct time manually; enable the system’s automatic date, time and time-zone options, then restart the client. This is especially important if the device has been sleeping for a long time, its hardware clock is incorrect or the system has just been restored from a snapshot.

Make the smallest possible route change

Once the basic network is confirmed, update the subscription first, then select another route in the same region. This shows whether the issue is limited to one route while keeping the access region as consistent as possible. If all routes in that region fail, test another region. WeekVPN covers 90+ countries and 200+ routes; the routes page lists regions and route types, and you can use the global routes page to choose an alternative. During troubleshooting, the goal is to confirm whether a connection can be established—not to find the fastest route immediately.

If every route fails on the same access network but connects after you switch networks, check router access controls, corporate network policies and local security software. Do not permanently disable system protection just for testing. A safer approach is to review the security software’s block log, add explicit allow rules for the client and network services, then restore protection and retest. If other proxy, packet-capture, filtering or virtual-network tools are running, fully quit them to prevent multiple programs from competing for the system proxy or virtual interface.

Clear conflicts from old proxies and virtual interfaces

After an abnormal client exit, the system proxy may still point to a stopped local port, making every webpage suddenly inaccessible. Disconnect the client first, disable the manual proxy in system network settings, then reconnect. Desktop systems may also retain old virtual interfaces, DNS settings or routes. Do not delete every interface just because several are listed. Start with the client’s repair, network-reset or network-service reinstall option; only consider cleanup after confirming that an interface belongs to uninstalled software.

On Linux, also confirm that the client process has permission to create a tunnel and modify routes, and check whether proxy environment variables duplicate the system-level tunnel. You can inspect common proxy variables in a terminal, but do not submit output containing credentials to a public channel:

printenv | grep -i proxy
ip route
curl -I https://example.com

If command-line access works but the browser fails, the issue is most likely the browser proxy, an extension or the cache. If both command line and browser fail while the client reports a successful connection, continue to the next chapter for DNS and system-proxy checks. If the client consistently reports a handshake failure that reproduces across devices, networks and routes, preserve the exact error, time, platform and route name, then organize the evidence in the support-ticket chapter.

WEB AND DNS

Connected but websites will not open: check proxy takeover and DNS separately

First determine whether the domain fails or all traffic fails

A client showing Connected only means that the tunnel is established; it does not mean the browser, DNS and target website are using the same path. First compare different request types: do all ordinary webpages fail, or only one domain; when the browser fails, does a command-line request succeed; does the same site work through its app? If only domain access fails, focus on DNS. If the domain resolves but the connection times out, check the system proxy, routing and route. If only one website is affected, first rule out the site’s own status, regional requirements and browser cache.

Use the system’s built-in name-resolution tool to query a public test domain. The domain used here contains no account information and does not touch a real subscription URL:

nslookup example.com

# macOS or Linux can also use
dig example.com

If the tool returns an address but the browser still says it cannot find the server, the browser may have independent secure DNS, an extension rewrite or a stale cache. If the tool also returns nothing, the issue is more likely the system DNS, client DNS takeover or the current network’s resolution path. Do not treat one returned address as permanent; DNS results can change with the network and time. For troubleshooting, only check whether a result is returned, whether it times out noticeably and whether there is a consistent difference with the proxy on or off.

Check whether the system proxy actually points to the running client

System proxy mode depends on the local client continuing to listen. When the client process stops, its listener malfunctions or an old system-proxy setting remains, the browser sends requests to a nonexistent local endpoint. First disable the system proxy in the client and check whether the system network settings return to normal; then enable it again and immediately test an ordinary webpage. If access returns when it is disabled and fails when enabled, the issue is local proxy takeover, client listening or configuration mode—not the remote website.

The browser may have its own proxy settings. Enterprise policies, proxy extensions and developer tools can all override system settings. A temporary browser window without extra extensions can rule out some cache issues, but it cannot guarantee that enterprise policies are bypassed. A more reliable approach is to review the browser’s network settings and confirm that it follows the system proxy, or explicitly uses the local endpoint provided by the client. Do not let a browser extension and the system proxy take over the same request with different rules.

Handle DNS caches, independent resolution and altered results

After switching routes, the system and browser may continue using an old resolution result. Close the target tab, clear the site cache and DNS cache, then open it again. At the system level, first disconnecting and reconnecting the network is usually enough; there is no need to begin with a high-risk network reset. If the client offers options such as “remote resolution” or “resolve through proxy,” save the original setting and change only that option to observe whether the domain recovers. Afterward, test the same domain only so differences between multiple websites do not obscure the result.

Some apps use their own encrypted DNS and ignore system settings; others depend entirely on system resolution. As a result, a browser may work while an app fails, or the reverse. Do not simply conclude that the route is unavailable. Check whether the affected app allows independent DNS to be disabled, whether a private-network feature is enabled and whether the app is routed directly. On mobile, also check Private DNS, content filters and other network extensions that may be active at the same time.

Handle individual websites and certificate warnings

If only one website will not open, use the same route to visit other ordinary websites and confirm that the overall connection works. Then clear that site’s cookies, cache and old sign-in state, or retest in another browser. The target service may provide different content based on the exit region, so choose a route matching the service’s regional requirement rather than selecting randomly. For animation, streaming and Japan-region content, see the Japan Route Selection Guide to understand the relationship between region and exit address.

When you see a certificate warning, do not ignore it and continue. First confirm that system time is synchronized automatically, check the URL spelling, then perform a controlled test with software that may filter web traffic or inspect certificates disabled. If several trusted websites show certificate errors at once, stop visiting sensitive pages immediately, restore system network settings and check local security software. A certificate error is not simply “slow speed,” and repeatedly switching routes is not an appropriate way to hide it.

By the end of this chapter, you should be able to classify the issue as failed resolution, system proxy not taking over, an independent browser setting, a single-site cache problem or a regional mismatch. If webpages work again but video, downloads or meetings remain slow, continue to the speed chapter. If the browser works while one app still fails, go directly to the app-routing chapter.

SPEED AND PEAK HOURS

Slow speeds and peak-hour lag: separate local bottlenecks, routes and the target service

Fix the test conditions before diagnosing speed

“It feels slower” is not enough to identify the cause. Slow initial page loads, video buffering, slow downloads, meeting jitter and higher game latency depend on different network characteristics. Webpages are more sensitive to DNS and initial connection setup; video depends more on sustained throughput; meetings are sensitive to jitter and packet loss; large downloads are also affected by source-side limits. Choose one specific scenario before testing, and keep the device, access network, target service and time period consistent while comparing routes. Do not directly compare results from different websites, resolutions or download sources.

First stop bandwidth-heavy syncing, backups, system updates and large file transfers. Then confirm that the local wireless signal is stable; move closer to the access point or use a more stable connection when possible. If the connection is equally slow with the proxy off, the issue is on the local network or with the target service, and switching to an international route will not remove the underlying bottleneck. If the proxy-off test is normal but the connection becomes slow, continue with route-level checks.

Switch within the same region, then compare across regions

Start by replacing the route within the same region. This keeps the access distance and content region as consistent as possible, making it easier to determine whether only one route has changed. If all routes in that region are slow, compare with a geographically closer region. Greater distance usually means a longer propagation path, but distance is not the only factor; cross-border routing, the access provider and interconnections with the target service all affect the result. Do not assume that the city closest on a map is automatically the best route.

WeekVPN offers 90+ countries and 200+ routes. Check route types and regions on the routes page. Browsing, AI tools, streaming and remote work have different priorities. During troubleshooting, first find a stable, reproducible route, then consider the desired content region. Switching repeatedly makes apps rebuild connections, refresh resolution and revalidate sign-ins, which can make the experience worse in the short term.

Use time-based comparisons to confirm peak-hour issues

If lag appears only during a consistent busy period and other times are normal, it may be related to simultaneous load on the local access network, cross-border links or the target service. Do not test one route only during the incident and draw a conclusion. Record performance for the same device, network and target during a quiet period and a busy period, keeping all other conditions unchanged while switching only to another route in the same region during the incident. If several routes slow down together but another access network restores performance, check the local provider’s path first. If only one route is affected, use an alternative and record its name.

For video tests, fix the quality setting first so automatic quality does not change between tests. For meetings, focus on audio interruptions, frozen video and reconnections rather than download speed alone. For downloads, use the same source and file to avoid rate-limit differences between mirrors. Slow responses from AI tools do not necessarily mean a slow route; server queues, session length and page scripts can all add waiting time. Cross-check the network layer with an ordinary webpage and another service in the same region.

The more complex the configuration, the more important it is to check overhead

When global proxying, rule-based routing, in-app proxying and system-level tunnels are enabled together, traffic may pass through local processing more than once. Browser filtering extensions, web scanning by security software and system content filters can also increase connection setup time. When troubleshooting speed, temporarily return to the client’s standard mode, quit other proxy tools, keep necessary system protection enabled, then restore settings one by one. If speed changes immediately after restoring one item, the bottleneck is in the local processing chain rather than insufficient route coverage.

Insufficient plan traffic can also affect normal-use tests, so check subscription status and remaining traffic in the user panel. Monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB; traffic resets monthly on the activation date, and an upgrade mid-cycle converts the price difference into remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they last until used and never expire. Here, only verify that the account still has usable traffic; do not treat a plan upgrade as a universal fix for speed issues. See the Plans and Pricing page for the applicable rules.

If several routes show the same problem during the same period under fixed conditions, record the access-network type, target service, route region and reproducible time window. Do not submit only a speed-test screenshot; it cannot show the actual app, target path or test conditions. Reproducible steps are more useful for diagnosis than a one-off result.

DISCONNECT AND MOBILE

Frequent disconnects and mobile background drops: check system scheduling and network changes

First distinguish a route drop from an app being suspended by the system

Frequent disconnects are often described simply as “unstable,” but they may actually be caused by a dropped route session, switching between Wi-Fi and cellular data, the client being paused by battery-saving rules, the system reclaiming a background process or another network extension taking over the tunnel. Start by checking the client status when the disconnect occurs. If it clearly changes from Connected to Disconnected, inspect the exact error. If it still shows Connected but new requests fail, focus on network switching, DNS and local tunnel recovery. If returning to the client immediately restores access, background scheduling or battery restrictions are usually more likely.

Desktop devices can also disconnect after sleep. Closing the lid, entering standby, switching users or having a network interface obtain a new address may invalidate the old session. After waking the device, wait for the basic network to reconnect before letting the client connect again. Do not click Connect repeatedly while the wireless network is still authenticating. If the issue happens after every wake-up, check whether the client can start with the system, whether it has background-running permission and whether the system restricts network extensions.

On mobile, check battery-saving and background permissions first

Both iOS and Android schedule apps based on battery level, memory, network state and background-activity policies. First confirm that the client’s network configuration is still enabled, then check Low Power Mode, background activity permission and battery optimization for the individual app. If the system allows the client to be exempted from strict battery-saving limits, adjust it after understanding the effect on battery life. Do not disable every system security feature for troubleshooting, and do not grant permissions unrelated to network connectivity.

When there is little network activity after the screen locks, the system may suspend the app interface, while a system-level tunnel is usually maintained by a separate network service. If the connection repeatedly drops while locked, compare two situations: stay on the same Wi-Fi network, then leave Wi-Fi coverage and switch to another access network. If it drops only during the switch, session migration or network re-establishment is the main factor. If it also drops on a stable network, continue checking battery-saving policies, system network-extension conflicts and the selected route.

Check whether multiple network tools are taking over

On mobile devices, content filtering, device management, Private DNS, ad blockers and other network tools may share the system’s network-extension capabilities. Some systems allow only one primary tunnel to be active, so a later-starting tool can replace the earlier configuration. Record the currently enabled network extensions, temporarily disable other tools that alter the traffic path, and retest with only WeekVPN enabled. Restore them one at a time to identify the conflicting combination.

The situation is similar on desktop. Virtual machines, container networks, remote-work clients, packet-capture tools and other proxy programs all add routing complexity. If disconnects begin only after a particular program starts, check whether it changes the default route, DNS or system proxy. Do not let multiple programs configure a global proxy at the same time. If they must coexist, define each traffic scope clearly and avoid chaining local endpoints into one another.

Reproduce in a stable environment instead of chasing random drops

Intermittent disconnects are the hardest to diagnose, so simplify the environment. Keep the device plugged in, disable strict battery saving, stay on one access network, choose a standard route and continuously visit an ordinary webpage. If it remains stable, restore screen locking, network switching, background limits and other network tools one at a time. The step after which the issue returns is a useful clue. If it still disconnects in the simplified setup, switch to another route in the same region and then to another access network to build a cross-check between the route and local network.

Capture log lines immediately before and after the disconnect rather than submitting a full file containing long-term history and sensitive configuration. Note what was happening, such as the device just locking, switching from Wi-Fi, waking or starting an app. If the client offers automatic reconnection, enable it to see whether access returns, but automatic reconnection only reduces the impact and does not explain the cause. If the issue continues to reproduce frequently, submit a ticket with the evidence.

If mobile use is mainly for everyday browsing and video, first complete the basic setup in the Complete First-Day Guide for Beginners, then return to this chapter to adjust background behavior. An incomplete initial import, an outdated subscription and battery restrictions can occur together; make sure the main setup path is correct before addressing background stability.

SUBSCRIPTION AND ACCOUNT

Subscription update failures and device-count notices: verify the source, status and cache

When a subscription fails, first identify where the error occurs

A subscription update has three stages: fetching the configuration, parsing its contents and writing them to the client. A network error means the client did not retrieve the content successfully; a format or parsing error means the content arrived but the client could not interpret it; a write error may involve local permissions, configuration storage or an old file. Do not copy only the words “Update failed”; preserve the complete message and where it appeared. Wording varies by client, but the same three-stage diagnosis applies.

Log in to the user panel first and confirm the account and plan status, then obtain the WeekVPN client or subscription entry again from the panel. WeekVPN registration requires no email address; a username and password are sufficient. If you forget the username or password, do not create account after account to replace the original subscription. Use the login and support-ticket channels to resolve account issues. The subscription URL is private account information and should only be obtained from the user panel, never forwarded or pasted into a public testing website.

Rule out copy errors, cache and old configurations

When copying a subscription URL manually, leading or trailing spaces, line breaks, truncation and input-method substitutions can all cause an update to fail. The safer approach is to use the client’s paste or import function and confirm that the URL is complete. Documentation examples should always use an obviously fake value, such as:

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

If an old subscription worked before but suddenly reports a parsing error after an update, keep the old configuration and do not immediately delete every route. Create a separate configuration and import it again to determine whether the problem comes from stale cache. If the new configuration works, the original configuration storage or overwrite process is at fault; if both fail, check the network, account status and client compatibility. Obtain the client through the user-panel entry rather than installing a modified program from an unknown source.

A subscription entry opening in the browser does not guarantee that the client can update. The browser may reuse a signed-in session, while the client needs to fetch the configuration directly; the browser may also handle redirects automatically, while the client requires a specific response. Do not publicly inspect or share the response body because it may contain routes and credentials. Record only the client error type, whether another network fixes it and whether it reproduces in the WeekVPN client.

Understand “device limit exceeded” notices

WeekVPN has no device-count limit. If the client or another page shows a device-limit notice, do not first assume that the plan needs more device slots. Confirm that the imported subscription is actually the one provided by the WeekVPN user panel, rather than an old service, test configuration or leftover data from another account. Then determine whether the notice comes from the client, the target app or the subscription service. Its source changes its meaning.

Some clients limit the number of local configurations, simultaneously running configurations or authorizations managed by the app itself; this is not a WeekVPN device limit. Capture the screen containing the notice and keep the app name visible, then check whether multiple configurations are enabled. If the notice comes from the target website, it may refer to that site’s own signed-in-device policy and have nothing to do with the network-acceleration subscription. If the WeekVPN account shows an abnormal notice directly in the user panel, submit a ticket with the username, page location and exact wording, but never include the password.

Check traffic resets and package boundaries

If an update succeeds but routes cannot be used, check remaining traffic and plan validity. Monthly-plan traffic resets each month on the activation date, and a mid-cycle upgrade converts the price difference into remaining days; traffic packages last until used and never expire. Monthly plans and traffic packages use different calculations, so do not infer a reset date from the calendar month or assume that a traffic package refreshes monthly. Plan details include ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB, plus traffic packages of ¥158/300GB, ¥358/1000GB and ¥658/3000GB.

If the user-panel status does not change as expected after payment, refresh the account page and sign in again, then check the order status. Payment methods are Alipay, WeChat and USDT. Do not submit the same payment again, and do not judge the order result by whether the client updates immediately. Orders, accounts and subscriptions are separate layers; a ticket should state separately whether payment completed, what the panel shows and what the subscription update returned.

If the issue concerns a refund after purchase, use the standard 14-day no-questions-asked refund policy in the main text; see the Terms of Use for specific eligibility and procedures. This troubleshooting page does not process refund requests, and re-importing a subscription does not change an order’s status. Describe technical and billing issues separately so the ticket reaches the right workflow.

APPLICATION ROUTING

One app does not use the proxy: check processes, rules and in-app settings

Confirm it is an app-specific issue, not a target-service issue

When the browser works but one app fails, first use the browser to visit that app’s official website or a similar service. If the browser also fails, the issue may still be the route, DNS or region selection; only if the app alone fails should you inspect processes and routing. Also check whether the app was recently updated, needs you to sign in again or is experiencing a service-status issue. A network connection can fix the transport path, but it cannot replace an app account, content permission or server-side status.

An app may use its own network stack and ignore the system proxy. A common pattern is that the browser follows the system proxy while a game, store, command-line tool or desktop client connects directly. In that case, use the client’s system-level tunnel mode or explicitly include the app’s domains and process in the rules. Names vary by platform and client, so back up the existing rules first and avoid adding an overly broad match condition in one step.

Check routing rules by their match results

Rule-based modes usually match from top to bottom, and the first matching rule determines the traffic path. If a broad direct-connection rule appears before the app rule, later proxy rules will not take effect. Open the client’s connection log or rule-match information, launch the target app and observe which rule handles its domain or process. Do not infer all domains from the app name; sign-in, content, updates and APIs may use different domains.

If the client provides no visible match log, temporarily switch to global proxy mode for comparison. If global mode restores access while rule mode fails, the route itself works and the issue is in traffic splitting. After the comparison, restore the original mode and add explicit rules instead of relying on global mode permanently. Global mode may also reroute local services that do not need a proxy, so it is suitable only for short diagnostic tests.

Check in-app proxies and environment variables

Some development tools, terminal programs and desktop apps have their own proxy settings. When the in-app setting is empty, the app may follow the system; when an old address remains, it may bypass the current client and connect to a stopped local endpoint. Check the app’s HTTP, HTTPS, SOCKS and “use system proxy” options and remove stale values. If unsure, record the original configuration, restore system-proxy mode and test again.

Command-line tools may also read environment variables. You can check whether the variables exist, but do not share output containing authentication information:

printenv | grep -i proxy

# An obvious fake value for the current terminal only
export HTTPS_PROXY=http://localhost:PORT

The PORT in the example must be replaced with the local port shown in the client interface; do not guess it. With a system-level tunnel, extra environment variables are usually unnecessary, and setting them again may create an unnecessary path. On Windows, check the app’s own network settings and the system proxy; on macOS, also check network extensions; on Linux, distinguish desktop proxy settings, environment variables and route-level tunnels.

Where streaming, AI tools and local services differ

Streaming apps may determine available content from the exit region, account region, content rights and cache together. A browser opening the homepage does not mean every in-app title will play. Choose a route that matches the target region, fully close and reopen the app, and clear stale regional cache. AI tools may depend on several API domains; proxying only the main site while missing sign-in or static-resource domains can produce a page that opens but cannot submit requests. Use match records to complete the rules.

Local printers, LAN storage and internal business services should generally stay on the local path. If global mode breaks them, do not force internal addresses through a remote route; restore rule mode and keep local resources on a direct connection. The goal of routing rules is to define the boundary clearly: apps that need cross-border access use the appropriate route, while local resources continue using the local network.

If the target app still fails in global mode while the browser can access the same service, record the app name, platform, route region, in-app error and whether it uses independent DNS. If the app works on another device, include the differences between the working and failing devices. Do not write only “this app doesn’t work,” because that gives a ticket no way to distinguish rules, account status, app version and target-service issues.

TICKET AND EVIDENCE

When to contact support: turn the ticket into a reproducible record

When it is appropriate to submit a ticket

Submit a ticket when the issue still reproduces consistently after checking the basic network, subscription, route, DNS and app routing. This is especially appropriate when the same error appears across different devices, access networks and multiple routes, or when the order, plan or subscription status in the user panel does not match the actual result. Reinstalling repeatedly has little value in these cases. Another clear case is when the client continues returning the same exact error despite a normal restart, subscription update and same-region route switch.

An individual website that is intermittently unavailable, a public network that has not completed authentication or ordinary webpages that remain inaccessible with the proxy off should usually be handled as an external-environment issue first. Only after these conditions are ruled out can a ticket focus on what WeekVPN can inspect. Keep technical and billing tickets separate: describe platform, network, route and error in a technical ticket; describe order status, payment method and user-panel display in a billing ticket. Do not copy large amounts of unrelated history into one message.

What to include in the ticket

Start an effective report with the conclusion. For example: “On Windows, the client connects but no domain resolves; the same account works on Android; switching access networks does not help.” Then describe the environment: platform, client source, access-network type, route region, proxy mode and whether system or routing settings changed before the issue began. If the exact version is uncertain, do not guess a version number; simply state that the WeekVPN client from the user panel is being used.

Next list the shortest reproduction path: open the client, update the subscription, select a route, launch the target app and note the message shown. The steps should let support repeat the issue under similar conditions. Then list completed checks and their results, such as basic network access working with the proxy off, the same result on other routes in the region, another device working or no change after clearing DNS. Do not write only “I tried everything,” because that does not show which actions were actually taken.

Screenshots, logs and privacy boundaries

Screenshots should include the error and the page where it appears, not just a small crop with no context. Before submitting, hide the password, full subscription URL, access token, QR code, sensitive order information and other account content. A username can help locate the account, but never submit the password. If logs contain configuration content, first copy them into a text editor, remove subscription URLs and credentials, then attach only the relevant lines before and after the failure.

The exact error text matters more than a paraphrase. “Connection timed out,” “Resolution failed,” “Authentication error” and “Invalid configuration” are not interchangeable. If the error is in English or is a system code, copy it exactly and add an explanation afterward if needed. Use the date and time zone shown by the device rather than writing only “just now.” If the issue is tied to busy periods, state the reproducible time range and access network; there is no need to provide an unverifiable speed-test conclusion.

Additional information by issue type

For connection failures, include client status, exact error, whether the basic network works and whether the issue reproduces across networks. For inaccessible websites, include the difference between ordinary and target webpages, whether DNS returns a result and whether the browser and command line behave the same. For speed issues, include the specific scenario, fixed target, route region and whether it occurs only during a particular period. For frequent disconnects, state whether they relate to screen locking, sleep or network switching. For subscription-update failures, include the failed stage, user-panel status and whether the issue reproduces in another client.

For an app-specific failure, include the app name, platform, global-mode versus rule-mode comparison, rule-match result and whether the browser can access the same service. For a device-count notice, capture its source and confirm that the subscription comes from WeekVPN; because the service has no device-count limit, this helps distinguish a client, target-service or old-configuration restriction. For billing issues, state whether payment used Alipay, WeChat or USDT, but do not upload complete payment credentials to a public area.

What to do after submitting a ticket

After submitting, keep the reproducible environment whenever possible. If you must continue working, switch to a confirmed working route, but do not delete the original configuration or logs. When support requests an additional test, perform one specified action at a time and report the result, rather than changing several settings at once. If the issue resolves on its own, report when it recovered and whether the network or route changed; these details help distinguish an intermittent external condition from local configuration recovery.

WeekVPN supports 90+ countries and 200+ routes, has no device-count limit and provides a 14-day no-questions-asked refund. The purpose of technical troubleshooting is to identify whether the connection issue lies with the device, access network, client, route or target service; it does not replace order or refund terms. See Plans and Pricing for plans, traffic and prices, Routes for regions and route types, and return to Quick Start for installation and the first import.

Once this manual gives you stable reproduction conditions, there is no need to expand the test scope. Keep the minimal environment, clear error and cross-check results, then open a ticket from the user panel. Without stable reproduction, continue recording the fault boundary and, the next time it occurs, test only the variables that remain unconfirmed. Troubleshooting is not about trying every switch; it is about ruling out each layer until one explainable scope remains.