VPN Troubleshooting Guide

DIAGNOSIS METHOD

Troubleshooting method: define the failure boundary first

This page is a systematic reference for situations where installation and subscription import are complete but the connection does not behave as expected. If you have not finished creating an account, choosing a plan, obtaining a subscription, or importing it into a client, start with Quick Start. Quick Start gets the connection established; this page explains why it fails, how to narrow the scope, and when to involve support. The two pages serve different purposes, so do not jump straight to route tuning before the subscription has been imported correctly.

Turn vague descriptions into verifiable symptoms

“It does not work” is not precise enough for diagnosis. First check whether the client shows a connected state, then determine whether every website is inaccessible or only a particular site or app. Next check whether the issue occurs only on one network, device, route, or time period. A connection that cannot be established at all usually calls for checks of permissions, the local network, system time, subscription validity, and protocol compatibility. If the client shows connected but websites do not open, focus on the system proxy, DNS, routing rules, and browser cache. When only one app is affected, do not repeatedly reinstall the entire client; check whether that app is bypassing the system proxy.

Establish a stable baseline for troubleshooting. Pause large file transfers, cloud sync, and system updates, and close security software, debugging proxies, or old clients that may alter the network path—but do not change several system settings at once. Choose one client, one route, and one ordinary webpage as the baseline. Retest and record the result after every action. If you switch routes, change proxy mode, replace DNS, and reinstall the client all at once, even a recovery will not reveal which step helped, and the next occurrence will still require starting over.

Check from the nearest layer outward

Check in this order: local network → client status → subscription contents → route connection → DNS resolution → target app. This prioritizes the layer closest to the device and easiest to verify. If ordinary webpages remain inaccessible after disconnecting, the issue starts with the local network; do not keep switching remote routes. If the client cannot read the subscription, a complete-looking route list does not prove the configuration is valid. Only after the local network works, the subscription updates, and the client can establish a connection should you assess the target service’s region, route type, and routing rules.

Also distinguish configuration problems from environmental changes. If failure begins immediately after importing a subscription, suspect the import method, permissions, or client mode. If it worked until the network changed, check the new network’s restrictions and DNS first. If it worked until a system update or another network tool was installed, check virtual adapters, the system proxy, and changed permissions. If it only slows down in the evening, compare route types in the same region instead of deleting the account and creating a new one. Searches such as “VPN software cannot connect” often point to these basic network, configuration, or routing issues, which should be handled layer by verifiable layer.

Prepare a minimal reproduction record

For every test, record at least the platform, client status, route name, time, network type, failed target, exact error text, and actions already taken. Windows, macOS, iOS, Android, and Linux use different permission models and proxy-handling methods; writing only “desktop” or “mobile” loses important context. Copy the exact error or attach a screenshot instead of paraphrasing it as “an error.” Record the complete route name, not just the region, because one region may include IEPL, relay, and direct routes.

CONNECTION FAILURE

Cannot connect at all: rule out each entry condition

“Cannot connect at all” means the client fails during connection setup: it remains stuck connecting, quickly returns to disconnected, or shows a handshake, timeout, permission, or unavailable-configuration error. Do not start with websites or Streaming, because traffic has not reached a usable route. The goal is to confirm that the client has usable configuration, the system allows it to take over networking, the current network can reach the route entry point, and the selected route is not a single-route failure.

Verify the basic network without acceleration first

Quit the client completely instead of merely minimizing its window, then use a browser to open an ordinary webpage that normally works. If ordinary pages also fail, restore Wi-Fi, Ethernet, the router, or the upstream network first. Disconnecting and reconnecting the current network can help; when possible, compare with another network environment. The purpose is not to adopt the other network permanently, but to see whether the failure is tied to the current one. If the client connects immediately after switching networks, the account and subscription are probably usable; focus on DNS, gateway policy, or network permissions on the original network.

After the basic network is restored, check that the device date, time, and time zone are maintained automatically by the system. Many encrypted connections depend on certificate validity, and an incorrect system clock can appear as a handshake failure, certificate error, or persistent timeout. Do not bypass the issue by ignoring certificate errors; correct the system time and restart the client first. Then confirm that no other VPN, debugging proxy, packet-capture tool, or virtual-network software is running. When similar tools modify the default route simultaneously, traffic may be sent into an old tunnel, creating a loop or immediate timeout.

Check permissions, configuration, and client status

On first launch or after a system update, the client may need permission again for a VPN configuration, network extension, virtual adapter, or background operation. On Windows and Linux, check whether the virtual adapter was created and whether the client has sufficient permissions. On macOS, check whether the system is waiting for approval of a network extension. On iOS and Android, confirm that the VPN configuration still exists in system settings. After a permission prompt is dismissed, the client may still let you click Connect, but the system will not create the tunnel. Repeated clicks will not help; quit the client, grant permission in system settings, and launch it again.

Confirm that the subscription list contains selectable routes and that route names and type labels display correctly. If the list is empty, contains only old routes, or shows an abnormal update time, go to the “Subscription updates” section on this page first. If the list is normal, choose a commonly used route in a region relatively close to your current network path as the baseline. Avoid complex manual rules or custom configuration early in troubleshooting. VPNCF covers 120+ countries / 170+ routes; see Global Locations for region and route-type details. Compare different route types in the same region first, then compare other regions, so you can distinguish a single-route failure from a client entry-point problem.

Use the error stage to choose a direction

An error that appears immediately after clicking Connect is usually closer to configuration parsing, permissions, or the virtual adapter. A timeout after waiting points more toward the network path, route entry point, or DNS resolution. A connection that briefly succeeds and then drops calls for a check of whether another network service is rewriting the route. If the error text contains configuration field names, reimport the subscription instead of guessing field values manually. If it points to a certificate or time issue, fix the system clock first. If only one route times out, keep its name and test other types in the same region; there is no need to delete the entire subscription.

Windows:
ipconfig /flushdns

macOS:
dscacheutil -flushcache

Linux:
ip route
resolvectl status

These commands are used to clear the local DNS cache or inspect routing and resolution status. They will not repair an invalid subscription or replace client permission settings. Save any work before running them. Afterward, quit and reopen the client completely, then repeat the test on the same route. If a command is unavailable or the system reports insufficient permissions, do not download an unknown repair tool; use the network-diagnostics options provided by the operating system.

WEB AND DNS

Connected but websites will not open: check the system proxy and DNS

A client showing “Connected” only means that the tunnel or proxy process has been established; it does not guarantee that browser requests are taking the correct path. When websites fail to open, determine whether requests are leaving the browser, whether the domain resolves, whether the system proxy is active, and whether routing mode is sending traffic to the wrong exit. This differs from “cannot connect at all”: repeatedly reimporting the subscription is usually of limited value, so focus on traffic handling after the connection is established.

First distinguish all websites from one domain

Test an ordinary webpage that normally works and the target webpage separately. If every website fails, check whether the system proxy points to an old client that has been closed, whether the current client has system-proxy takeover enabled, and whether the browser has its own proxy setting. Some browser extensions override system settings; temporarily disable related extensions and restart the browser. If only one domain fails, try another browser or a private window to rule out cache, cookies, stale service workers, and extensions. Do not treat a single-site issue as proof that the entire route has failed.

Next, compare the client’s global mode with its rule mode. If global mode works but rule mode fails, the connection itself is generally usable; the likely issue is rule matching, domain classification, or app bypass. If rule mode works but global mode fails, check whether the selected route is suitable for all traffic and whether local services need to remain direct. Restore the original mode after the comparison instead of leaving diagnostic settings in place. For route selection by use case, see How to Choose a VPN Route: Region, Route Type, and Use Case Explained.

Determine whether DNS resolution is failing

DNS converts domain names into network addresses. When the connection is established but the browser reports that the server cannot be found, the name cannot be resolved, or the domain does not exist, check the resolution path first. Use the system’s built-in lookup tool in a terminal to see whether the domain returns a result. If the lookup fails while a known service responds directly, DNS is the likely cause. If the domain resolves but the connection times out, suspect the route, routing, or the target service instead. Do not copy unknown public DNS addresses at random: different networks and routing modes require different resolution paths, and blind replacement can make local resolution inconsistent with traffic exiting remotely.

Windows:
nslookup example.com

macOS / Linux:
dig example.com
nslookup example.com

The example domain is only for demonstrating the lookup process and contains no real subscription information. When reviewing the output, focus on whether the command returned a result, whether it stalled, and which resolver the system actually used. If the client offers “Use client DNS,” “Follow system,” or a similar option, use the recommended default to establish a baseline, then compare settings one at a time. After switching, clear the browser and system caches and restart the target app; otherwise old results may be reused and make the setting appear ineffective.

Clear leftover proxies and incorrect routes

After an abnormal client exit, the system proxy may still point to a local port that no longer exists. A typical sign is that every webpage fails when the client is closed but works again when it is reopened. Turn off the leftover manual proxy in system network settings, or use the current client’s “Restore system proxy” function. If several network tools have been installed, check for leftover virtual adapters and automatic proxy scripts as well. Confirm ownership before removing components; do not remove settings required by a company network, development environment, or security software.

In Linux, command-line programs may not read the desktop system proxy. If the browser works but terminal tools fail, check for stale environment variables and whether the command supports HTTP, HTTPS, or SOCKS proxies. Conversely, if the terminal works but the browser fails, check browser extensions, independent DNS, secure DNS, and proxy settings first. Windows and macOS can also have browsers using independent encrypted DNS and bypassing client resolution; temporarily restore browser defaults for comparison.

SPEED AND PEAK HOURS

Slow speeds and peak-hour lag: inspect each link

Speed issues cannot be judged from a single speed test. A slow first page, video buffering, download fluctuation, meeting lag, and API timeouts place different demands on the network. A high one-time peak does not prove stable sustained transfer, and a webpage opening quickly does not prove that long-lived connections will remain steady. Define the workload first: is all traffic slow, or only video, file transfers, real-time calls, or a particular destination region? Does it persist all day or appear mainly during busy hours? Route comparisons are meaningful only when the use case and time window are clear.

Rule out local bandwidth competition and wireless interference

Disconnect the acceleration connection first and test the basic network on the same device and in the same location. If the basic network is already losing packets or fluctuating, a remote route cannot fix the local access problem. Check whether cloud sync, system updates, game downloads, home media devices, or other endpoints are using upstream or downstream bandwidth. Real-time meetings especially depend on stable upstream capacity; background uploads can leave webpages usable while making voice and video noticeably choppy. Wireless connections are also affected by distance, obstacles, and interference. When possible, compare with Ethernet or a position closer to the access point, while keeping all other test conditions unchanged.

Disable duplicate proxy chains and unnecessary traffic-analysis features in the client. If a browser extension sends traffic to another local proxy before the client forwards it, it adds failure points and may create a routing loop. HTTPS inspection by security software, packet-capture proxies in development tools, and container networking can also change connection behavior. During diagnosis, keep one clear traffic-takeover method active. Restore other tools one at a time only after stability is confirmed, repeating the same workload test after each change.

Compare route types instead of only changing regions

When choosing a route, keep the destination region fixed and compare IEPL, relay, and direct routes. IEPL is a good first test for sustained access that requires link stability. Relay routes optimize the path between entry and exit and suit everyday cross-border use. Direct routes are simpler, but depend more on the current carrier and international link conditions. The point is not to declare one type universally faster, but to keep the test variables clear. Compare types in the same region first, then try a nearby region, so distance and route structure do not change simultaneously.

If only a particular content service is slow, consider its regional entry point and content-delivery strategy. A nearby region may not connect to the most suitable content node, while a distant region may add path length. For Streaming, see Recommended VPN Routes for Stable 4K Streaming: Why Quality Falls to 480p and Which Metrics Matter, but do not focus only on the resolution label. Check sustained buffering, whether seeking restores playback, whether ordinary webpages work on the same route, and whether another route type in the same region changes the result.

How to compare peak-hour performance correctly

Reproduce peak-hour lag during the period when it actually occurs. Recovery after switching routes during the day does not prove the same route will perform at night. Use a fixed set of test targets and record page loads, continuous playback, file transfers, or business requests during both normal and busy periods. Do not directly compare results from different websites, devices, or networks. If one route fails only during busy hours on a particular network but works on another access network, the issue is more likely between the local carrier and the entry point. If multiple access networks show the same route failing at once, record the route name and switch to an alternative in the same region.

Frequent concurrent speed tests can saturate the link and make other apps appear slower. Base diagnosis on real workloads, using speed tests only as supporting evidence. For video, watch sustained transfer and buffering. For developer APIs, check connection setup, timeouts, and long-connection stability. For webpages, check time to first byte and whether resources load completely. AI API workloads differ from browser workloads; see Recommended Routes for ChatGPT/Claude APIs: A Developer Selection Guide to assess fixed exits, concurrent connections, and timeout controls rather than peak speed alone.

DISCONNECTION AND MOBILE

Frequent disconnects and mobile background dropouts

For frequent disconnects, first distinguish an intentional disconnect, a network change, and system reclamation. An intentional disconnect usually leaves a clear event in the client log. A network change occurs between Wi-Fi and cellular networks, access points, or sleep and wake. System reclamation is common on mobile devices when power management pauses the client process or VPN extension in the background. All three may appear as “reconnecting,” but the fixes are entirely different. Record what happened to the device immediately before the disconnect, not only the error that followed.

Check network changes and sleep/wake transitions

If the connection is stable while the device remains still but drops after moving, locking the screen, closing the lid, or waking from sleep, check network transitions first. When a laptop switches from Ethernet to Wi-Fi or a mobile device switches from Wi-Fi to cellular, the local address and exit path have changed, so the old session usually cannot be reused. The client should establish a new connection; if automatic reconnection fails, disconnect and reconnect before deleting the subscription. If it happens repeatedly, record the network types and client status before and after the switch to determine whether it occurs in only one direction.

After desktop sleep, the virtual adapter may return later than the ordinary network adapter, causing the client to reconnect too early and fail. Wait for the basic network to recover fully before connecting manually, or enable the system-supported automatic reconnection option in the client. If every wake requires a client restart, check whether a system update requested approval again for the network extension or virtual adapter. Do not permanently mask the issue by disabling all sleep and power-saving features; that increases power use and removes useful diagnostic information. First determine whether the cause is system recovery timing, client permissions, or a session on a specific route that was not released.

The permission path for mobile background dropouts

Both iOS and Android manage background activity, but their behavior differs. On iOS, confirm that the system VPN configuration remains permitted; low-power conditions, network changes, and system reclamation can trigger reconnection. On Android, check battery optimization, background activity, data saving, and the manufacturer’s app-sleep policies. Notification permission alone does not provide continuous background operation. In system settings, find the app, allow the necessary background network activity, and keep it out of automatic-freeze or deep-sleep lists.

Use a clear mobile troubleshooting flow: keep the screen on in the foreground and confirm that the connection and webpages work; lock the screen, wait for the app to enter the background, then unlock and check the connection; finally test movement within Wi-Fi, switching between Wi-Fi and cellular, and low-power conditions separately. Test one change at a time. If it also disconnects in the foreground, this is not simply background reclamation; return to the route and basic-network checks. If it drops only after screen lock and recovers immediately when the client is reopened, prioritize background permissions and power-saving policies.

Distinguish a route disconnect from an app’s long-lived connection dropping

Sometimes the client still shows connected while a meeting, messaging app, or developer tool requires a new login. This may be an interrupted app-level long-lived connection, not a dropped VPN tunnel. When it occurs, open an ordinary webpage immediately and check whether other apps can still reach the network. If webpages work and only one app reconnects, check that app’s keepalive, proxy support, and background permissions. If all requests stall, inspect the client log to see whether the connection was rebuilt. An app resuming from the background may also create a new network session; an expired old session is app-layer behavior.

A router or upstream network may also terminate long-idle sessions, causing periodic disconnects. Do not infer a fixed interval from “about every so often.” Record the exact time, whether traffic was active, whether the screen was locked, and whether the network changed. If continuous activity remains stable but idle periods lead to drops, try the client’s keepalive or on-demand connection settings. If drops also occur during sustained transfer, compare different route types and access networks.

SUBSCRIPTION UPDATE

Subscription update failed: verify the URL, authentication, and cache

Subscription updates deliver available routes and related configuration to the client. A failed update does not necessarily mean the routes are faulty; the client may be unable to reach the subscription entry point, the login session may have expired, the old cache may be damaged, the system clock may be wrong, or the import method may not be supported by the client. First identify whether the failure occurs while fetching the subscription or parsing the configuration. The former usually appears as a network error, authentication failure, or unreachable address; the latter as a format, field, or configuration-parsing error.

Retrieve the subscription again from the user panel

Obtain the subscription from the user panel, not from a static installer link or subscription text forwarded by someone else. After signing in, open the Clients and Subscription page, confirm the current account status, and copy or import it according to the platform instructions. VPNCF registration requires no email address; a username and password are enough. When troubleshooting login issues, confirm that you are using the username created with the account rather than entering other information in the username field. A subscription is an account-access credential and should not be posted in public chats, forums, or screenshots.

If the client retains an old subscription entry, do not repeatedly paste over it. Record the original settings first, then create a separate entry and import the subscription there. This helps distinguish damaged old cache from content that cannot be parsed. If the new entry updates normally, delete the old one only after confirming that the route list is complete. If both entries fail, check the system clock, basic network, and supported import method. Do not edit protocol fields in the subscription manually to “repair” parsing: one incorrect character can disable every route, and a later update will overwrite the manual change.

Check network access and system time

Subscription updates usually happen before a route connection is established, so they depend on the current basic network. Disconnect the client and confirm that the user panel opens normally. If the panel is also inaccessible, fix the local network first. If the panel opens but the client update fails, check whether the client is incorrectly forcing the update through a proxy that has not been established. Some clients offer “Update through proxy” or a similar option. For the first import, use a path that can reach the subscription entry point to avoid a loop where a route is required to obtain the route.

An incorrect system clock can also cause the subscription entry point’s secure-connection check to fail. Restore automatic date, time, and time-zone management, then quit the client completely and test again. If the browser can open the panel but the client reports a certificate, handshake, or secure-connection error, check the time and client runtime first. Do not disable certificate validation or paste subscription content into an untrusted online converter. Conversion exposes the full subscription credential and may produce a configuration that can no longer update.

Identify cache, format, and import-method issues

If the client downloads content but reports a parsing failure, confirm that you used the import method provided by the panel for that platform. Clients accept different formats; do not assume the same content can be read directly by every program. If you pasted the subscription URL into a browser, text editor, or chat tool, copying may have added spaces or line breaks or truncated characters. Copy it again from the panel using its copy button or import entry point; do not assemble it manually. Examples should use clearly fake values, such as:

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

This address only illustrates the structure and cannot be used to connect. A real subscription URL should not appear in a ticket body, public screenshot, or shared document. When support needs to investigate, report “subscription update failed” with the error text; support can use the account context in the ticket without requiring the full credential. If a screenshot contains a QR code, long URL, or token, cover the sensitive portion first.

If the update succeeds but the route list does not change, check whether the client is still showing an old configuration group, whether the new subscription must be selected manually, and whether the configuration was reloaded after the update. Some clients allow multiple subscriptions, and the interface may still have the old entry selected. Verify the subscription name and update time, then check that the route list matches. If only some routes are missing, do not add them manually; record the missing regions, client platform, and subscription entry name and report them through a ticket.

APPLICATION ROUTING

An app bypasses the proxy: check the routing path

If the browser works but one app cannot connect, the tunnel and subscription are generally usable; the issue is likely how that app makes network requests. It may read the system proxy, use its own proxy setting, create direct connections, use built-in DNS, or communicate through processes unlike the browser’s. Do not change accounts or repeatedly reinstall the client first. Confirm whether the traffic enters the proxy, where the rules send it, and whether the app must restart before reading new settings.

Confirm whether the app supports the system proxy

Many desktop apps read the system proxy, but some ignore system settings entirely. When the client only enables system-proxy mode, an app that ignores it may continue connecting directly. If the client offers a virtual-adapter or global-takeover mode, use it for comparison. If the app recovers, the route is usable and the app did not enter the proxy in the original mode. If it still fails, continue with checks of the destination region, DNS, and app account status. Choose the mode that fits the actual use case afterward; do not assume every app needs permanent global takeover.

If the app has its own proxy settings, check for a stale address, port, or incorrect protocol. Do not copy local ports from random online instructions: the port depends on the current client configuration and may change after reinstalling or switching modes. Prefer the client’s system takeover or connection-information copy feature. After changing an independent proxy setting, quit and restart the app completely; closing its window may leave a background process and old connection pool using the previous path.

Check rule matches and process boundaries

Rule mode usually decides between proxy and direct access by domain, address, process, or app package name. A target app may access separate domains for login, content, updates, and telemetry, so a rule for only the main domain may not cover the full flow. During diagnosis, use global mode first to confirm that the app works on the current route. Then return to rule mode and inspect logs or the connection list to see which exit received the failed request. If global works but rules fail, adjust the rule boundary. If global also fails, routing is not the only cause.

Desktop apps often use several cooperating processes. The main window process may only handle the interface, while an updater, background service, runtime, or child process makes the actual network requests. Rules based only on the main program name may leave background requests direct. Use client connection logs to identify the process and domains that actually made the requests instead of guessing from filenames. Mobile apps may use system network services or embedded browser components, so validate rules against both the app package and its domains.

Rule out app cache, protocol, and region issues

Apps cache DNS, region information, and connection pools at startup. After switching routes, the browser may change immediately while a running app continues using old connections. Quit the app’s background processes, confirm that the client connection is stable, and reopen it. If the app account or content has regional requirements, the route region must also match the target service; a webpage opening does not prove that every region supports every in-app feature. For Streaming, see the regional selection guidance in Streaming Access; for AI Tools, see the AI Acceleration guide.

Some apps use UDP, long-lived connections, or custom transport methods, while the current proxy mode may handle only part of the traffic. The result may be that the login page opens but voice, game matching, sync, or real-time updates fail. Compare with the client’s full-takeover mode and observe which app functions recover. Do not test only the login page: a successful login proves that only part of the request flow is reachable. If the client log shows that target traffic entered the route but the app still returns a server error, keep the exact error and check the target service status or account limits.

DEVICE AND SUPPORT

Device notices, account status, and ticket materials

VPNCF plans support unlimited devices. If the client or a third-party import tool shows “device limit exceeded,” “abnormal connection count,” or a similar notice, do not assume it is a plan restriction. First identify whether the notice comes from the VPNCF user panel, the current client, the operating system, or an independent app. Different sources may use “device” to mean a login session, configuration instance, system VPN slot, app authorization, or an old connection that has not been released; these are not the same as this service’s device policy.

Handle device-limit notices

Confirm the account and plan status in the user panel first. Then check whether the same subscription was imported more than once, multiple clients are running, or several automatic-connection profiles remain on the device. Quit unused clients completely, remove duplicate VPN configurations from the system, and reconnect. If the notice appears in an independent client’s local interface, record the client name and full message instead of capturing only “limit exceeded.” If it comes from the operating system, check for old network extensions, virtual adapters, or enterprise-management profiles occupying the same connection entry point.

After changing devices, reinstalling the system, or an abnormal client exit, an old session may remain temporarily. Quit connections on other devices first, wait for the client to disconnect normally, then sign in again or reimport on the current device. Do not share account credentials with unrecognized devices or use unknown aggregator clients; their session management may not release connections correctly. If the account page is normal and the notice remains after other clients are closed, submit a ticket so support can check the session state using the account context.

Decide first whether support is truly needed

If one route fails while other routes in the same region work, use an alternative route for now and record the failed route name. If every route fails on one device but works on others, prioritize that device’s permissions, proxy, and network components. If every device fails on one network but works after switching networks, prioritize the original network. Submit a ticket directly when the same error appears across different devices, networks, and routes. This layered approach reduces back-and-forth questions and avoids misclassifying a local-environment issue as a service-side failure.

Handle billing and account issues through the support ticket portal in the user panel. VPNCF 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 mid-cycle upgrades are prorated by remaining days. Data packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire. If the issue concerns the displayed plan, traffic reset, or upgrade result, state the plan name, operation time, and what the panel currently shows. Do not calculate the expected traffic or remaining period yourself.

Describe payment issues using facts only. VPNCF supports Alipay / WeChat Pay / USDT and provides 30-day no-questions-asked refunds. In a ticket, include the payment method, the order status shown in the panel, and the error message, but never submit a payment password, complete payment credentials, account password, or subscription URL. Screenshots should retain the order status and time while covering information support does not need. Refer to the Pricing page and the current user-panel display for plan details.

A ready-to-use support-ticket checklist

A high-quality ticket should include the issue title, time, platform, client, network type, route name, reproduction steps, expected result, actual result, exact error text, actions already tried, and whether the issue reproduces on another device or network. Do not title it only “It does not work.” Use a precise title such as “All websites fail to resolve after connecting on macOS” or “Connection paused by the system after Android screen lock.” Describe events in order and avoid combining separate incidents into one paragraph.

Issue symptoms:
Platform:
Client status:
Current route:
Network type:
Time of occurrence:
Reproduction steps:
Exact error text:
Actions taken:
Result on other devices:
Result on other networks:

Submit only log fragments close to the failure time, and check them first for subscription URLs, tokens, account passwords, or other private content. Screenshots should include the full error window and client status bar; a single line may omit important context. If the issue concerns one app, state whether the browser or other apps work. If it concerns speed, state the workload, time period, route type, and whether the local baseline network works instead of attaching only one peak-speed screenshot.

After support provides instructions, reproduce the issue under the original test conditions and report the result. Do not reinstall the system, switch between several clients, and change every network setting while waiting for a reply; the environments will no longer be comparable. If an alternative route has reduced the issue, retain the original route and time of occurrence for later comparison. Once resolved, add the final effective action to the ticket to close the loop instead of replying only “Fixed.”