VPN Connection
Troubleshooting

Can't Connect at All: Check Your Device and Route

Start with the Client Fully Disconnected

“Can't connect” could mean the client won't start, the connect button does nothing, a server test fails, or a website won't load. Each points to a different part of the connection. Note exactly what happens and copy the full error message. Then disconnect the VPN and check whether your usual websites load on your local network. If your internet connection is already down, first resolve any Wi-Fi sign-in, router, or ISP issue. Switching servers repeatedly won't help diagnose a problem with the underlying connection.

Public Wi-Fi may require you to accept its terms on a sign-in page before you can browse. Your device may show that it's connected while the browser redirects to an authentication page or requests remain stuck loading. Complete the network's sign-in before starting the client. Never enter information requested by a public Wi-Fi portal into the VPNPut login form, and don't give your subscription link to a network sign-in page. If you don't trust the connection, verify the page's source before proceeding.

Make Sure the Client Has Loaded Your Configuration

Open the client's configuration list and check that the selected profile is the VPNPut subscription you just imported—not an empty or sample profile, or a file left over from another account. Seeing server names only confirms that the client read a configuration; it doesn't mean the subscription is still valid. Next, sign in to Account Overview and check your plan status and remaining data. If anything looks wrong, save the message and follow the subscription checks below.

If the connection switch won't stay on, check for system permission prompts first. A desktop client may need permission to create a network interface or change proxy settings; on mobile, you may need to approve a system connection configuration. If a permission dialog was dismissed, the client may still show server names, making setup look complete. Check the authorization status in system settings. On a managed device, follow your organization's policies—don't disable security controls or remove management settings without permission.

Change Only the Route When Testing Another Exit

Keep the client mode unchanged. First try another route in the same region, then try an exit in a different region. Test the same website each time and note whether all routes fail or only a specific one. If only one route has a problem, the issue is more likely on that path. If every route fails but another network works, focus on your current internet connection. VPNPut offers 120+ countries / 220+ routes. See the server page for route types and how to choose one.

If multiple proxy clients are running on your computer, they may compete for the system proxy or virtual network interface. Quit clients you aren't using, then check whether the system proxy still points to a closed app. Don't remove system network components or run reset scripts from unknown sources. Before restoring default settings, take a screenshot of the current values. Work proxies, development tools, and remote access software may rely on them, so clearing everything can create new problems.

An incorrect system clock can cause secure connection checks to fail. Check the date, time zone, and automatic time settings, then reconnect the client. If the logs mention certificate validation, a handshake, or a configuration parsing error, keep those keywords in your notes. Don't disable certificate checks just to get a temporary connection. Whether the error occurred during authorization, configuration loading, or the remote connection is more useful for diagnosis than a generic failure icon.

After these checks, you can submit a support ticket if your basic connection and account status are normal, the subscription updates successfully, and routes in multiple regions still fail. Explain whether the client can establish a system connection, where the failure occurs, and whether switching internet connections changes the result. Include redacted logs. If you rely on remote access to maintain the device, don't reset its network settings without a recovery plan. Arrange a local way to operate or restore it first so troubleshooting doesn't cut off access.

Connected, but Websites Won't Load: Trace the Request

A Connection Doesn't Guarantee the Request Worked

A connected status usually means the client has enabled local forwarding or established a tunnel; it doesn't mean every app is using it. First identify whether no websites load, only international sites have issues, a specific site fails, or the site opens but sign-in doesn't work. Test a few familiar sites and note whether the error is a DNS lookup failure, a timeout, a certificate warning, or a message from the site itself. Don't group all of these under “no internet.”

If your browser says it can't connect to the proxy server, check that the client is still running and that the system proxy points to the active client. After sleep, an unexpected app exit, or a profile change, the system proxy may not have updated. Reapply the settings using the client's system proxy toggle, then fully quit and reopen the browser. Don't enter proxy addresses found online unless you know what the port is for; an incorrect value can break your regular connection too.

Use Routing Modes to Check Whether Rules Are the Issue

If the client supports it and you understand what the setting does, temporarily switch to a mode that sends all test requests through the selected exit, then retry the same destination. If it works in that mode but fails under rule-based routing, check rule matching, subscription rule updates, and whether the app is excluded. This test is only for identifying the route. Restore the mode you normally use afterward, so local traffic that should stay local isn't sent through a remote exit.

If only one website fails, check whether it displays a region, account eligibility, or risk verification message. An exit route changes how you connect; it can't grant account eligibility, change a service's supported regions, or override its terms. Avoid repeatedly refreshing sign-in or verification pages after switching regions, as this may trigger account security checks. For access requirements for AI services, see the AI Tools guide. A connected client alone doesn't guarantee that a service will be available.

Rule Out Browser-Specific Issues

Try another browser or a private session with extensions disabled to help distinguish browser extensions and cached data from system network issues. If a fresh session works, check proxy extensions, privacy extensions, custom security settings, and site data before changing plans. Before clearing site data, make sure you know how to sign in again. Don't erase all browser data or lower system-wide security settings just to access a website.

If a site's home page loads but images, sign-in requests, or videos don't, different resources may be taking different routes. Modern websites load content from multiple domains, so seeing the page shell doesn't prove all its dependencies are reachable. If you're comfortable with developer tools, check the failed request domains and error types in the Network panel. Otherwise, note the specific button, blank area, or error. Before sharing a screenshot, hide account names, private content, and sensitive request parameters.

If all browsers fail while the client shows as connected, check DNS and system routing next. If browsers work but a desktop app doesn't, see the app section. The website itself may also be temporarily down: if the same site returns similar errors across different networks and devices, don't keep changing your local configuration. Save the error text from the site so support can distinguish a response from the service itself from a connection-level error.

When contacting support, include the destination domain, what you were doing on the page, the error type, and whether other websites work. The domain alone is usually enough; don't share a full URL with private query parameters. For pages involving payments, identity checks, or private sessions, describe the issue in text instead of sending a screenshot. “The home page loads, but sign-in times out” is much more useful than “nothing works.”

Slow Speeds and Peak-Time Issues: Compare the Full Route

First, Identify What's Slow

A slow first page load, a slow file download, video buffering, and choppy meeting audio are different performance issues. First loads depend on DNS lookups and connection setup; sustained downloads are more affected by throughput and the destination server; real-time audio and video are more sensitive to jitter and packet loss. Test the activity you actually care about. Don't use download results to predict meeting quality, or rely on a client's server test to judge your whole experience.

Use the same device, internet connection, and destination, and note when the issue occurs before comparing exits. Pause system updates, cloud sync, and other heavy transfers during testing. Uploads from other devices on your home network can also affect responsiveness. A strong Wi-Fi signal doesn't rule out interference. If possible, test over Ethernet or closer to your access point, but there's no need to buy new equipment first.

Route Type Helps You Choose; It Doesn't Guarantee Results

IEPL, transit, and direct routes describe different network paths, but your actual experience still depends on your local connection, the networks along the way, and the destination service. A closer exit isn't always faster, and routes covering similar distances may take different paths. Choose an exit that meets the destination service's regional requirements, then compare performance for your actual activity. “Dedicated line” doesn't mean a route can never be congested, and one direct route performing poorly on your network doesn't mean all direct routes will.

For peak-time issues, look at when the slowdown happens. If the same task works during the day but multiple routes slow down in the evening—and switching internet connections clearly helps—your local gateway or a shared upstream path may be congested. If only one route degrades at the same time, report its name. Include the time and task so support can compare the issue with route maintenance or a problem at the destination service.

Observe Before Switching Routes Repeatedly

After switching exits, existing connections may continue using the old route, and a video player may keep using a cache or existing session. End the current test, reopen the task, and let new requests use the new exit before comparing results. Don't switch routes while paying, submitting a form, or uploading a file. The change may prompt the destination to recheck your session and make results harder to compare.

Gaming and video calls depend on different network qualities than downloads. If controls suddenly lag or audio drops out, a higher download speed may not help; check packet loss and competing traffic on your local network first. For more on these metrics, see Latency, Packet Loss, and Network Acceleration. For work, see Choosing Routes for Video Calls and Collaboration Tools.

If changing routes consistently improves a specific task, stick with the exit that works instead of switching repeatedly to chase a better number in the test screen. If routes in every region are slow and local browsing without the client is slow too, return to basic network troubleshooting. An overheating device, a persistently busy processor, or a disk bottleneck can also affect downloads and video. Check system resources to avoid mistaking a device limitation for a route issue.

For a performance support ticket, include the destination service, task, connection type, time of the issue, and how other routes performed under the same conditions. You can attach a redacted speed test screenshot, but don't treat a single result as a verdict on long-term service performance. You can still ask for help without comparison tests—just describe the impact, such as choppy call audio or a page save that times out. That's more useful than “the speed is bad.”

Frequent Disconnects: Identify What Triggers Them

Distinguish a Tunnel Drop from an App Reconnecting

An app saying it's reconnecting doesn't necessarily mean the client tunnel dropped. Check the system connection icon, client status, and other websites at the same time. If only one app is interrupted while other traffic works, the issue may be with that app's session or the destination service. If all requests stop and the client reconnects, investigate local network changes, system sleep, and route stability. Identifying the scope of the interruption helps you choose the right next step.

Note what happened just before the drop—for example, closing the laptop, waking the screen, switching Wi-Fi networks, joining a meeting, or starting another network app. Many seemingly random issues are tied to these events. Don't save only a screenshot after the connection comes back; the log entries just before and after the drop are more useful. If the client has log-level settings, leave the default level unless support asks you to increase it. This helps limit sensitive information and irrelevant output.

A Change in Internet Connection Can Disrupt Existing Sessions

Switching from Wi-Fi to another connection can change the device's underlying address and routes, so existing connections have to be re-established. Some clients reconnect automatically, but the destination app may keep a stale long-lived connection. Wait for the client status to stabilize, then reopen the app. Don't keep pressing Connect while the network switch is still in progress. If connections fail every time you switch networks, note the system and client details, and check settings for automatic connection or network changes.

After a desktop device wakes from sleep, the system may have paused its network interface, and the client may resume later than the browser or messaging apps. A brief loss of access after waking doesn't automatically point to a remote route issue. Check whether disconnects still occur when the device stays awake, then review its power settings. For long-running tasks, use a power plan that meets your device's security requirements rather than disabling every power-saving or security feature.

Keep Changes Easy to Reverse

With multiple network tools enabled, the system proxy, virtual interfaces, or routes may be rewritten repeatedly. The client may still show a connection while another app handles the traffic, or a closed app may leave behind a broken proxy setting. Quit nonessential tools one at a time, confirm which client currently manages your network, and reconnect. Don't enable several tools that take over all network traffic to “stack” acceleration; that usually creates conflicts instead of improving stability.

If disconnects occur only on a particular exit, keep the client and internet connection unchanged and try another region or route type. If switching routes fixes the issue, use the working route for now and report the original route name, time of the disconnect, and what you were doing. If switching routes doesn't help but changing internet connections does, check your router, Wi-Fi coverage, or ISP route. One successful reconnect doesn't prove the problem is permanently fixed.

Report disconnects after long periods of inactivity separately from drops during active use. Idle disconnects may involve power-saving settings, network equipment reclaiming a session, or the destination app's idle policy. Drops during active use are more likely to warrant checks for Wi-Fi interference, competing traffic, or route changes. After reconnecting, check whether the app needs you to sign in again or restart the task. File uploads, remote terminals, and calls often don't resume just because the client reconnects.

Don't start by reinstalling the client when disconnects keep happening. A reinstall may erase valuable logs and reset automatic connection, routing rules, and permissions. First export diagnostic information without credentials and note your current settings; then consider updating or setting up the client again. If the client came from somewhere other than the user panel, check the download source through the client download page. Don't use unofficial modified packages to fix connection issues.

When contacting support, say whether the drops are related to sleep, switching networks, idle time, or a particular app—and whether the client reconnects automatically. “The client reconnects after I switch networks, but I have to rejoin the meeting” is more precise than “it keeps dropping.” If a drop coincides with a system error, a disappearing network interface, or an unexpected restart, also investigate the operating system and hardware. Route support can't replace device maintenance.

Subscription Update Failed: Check the Link and Account Separately

What a Subscription Update Does

A subscription link lets the client retrieve the configuration and route list associated with your account. A successful update means the client received a readable configuration; it doesn't guarantee access to every website. A failed update doesn't necessarily mean every existing route is unusable. First check whether the current configuration still connects, then review the error from the update attempt. Treating configuration retrieval and route use as separate issues helps prevent deleting all your servers while the existing connection still works.

Sign in to the VPNPut user panel and check the subscription source in Account Overview. Don't use an old link from chat history, a configuration forwarded by someone else, or a subscription link from an unknown guide. Copy it using the link provided in the panel. Make sure the clipboard contains the complete link, without extra spaces, line breaks, or explanatory text. A subscription link is an account credential—never post it on a public forum, paste it into an online converter, or commit it to a public code repository.

Continue Based on the Error

If the error says the request timed out or couldn't connect, check the network route used to fetch the subscription. Some clients send updates through the current proxy, which can create a loop if the current configuration isn't working. Check whether the client lets you choose a proxy for subscription updates, and test the options only if you understand what they do. Don't change the subscription domain, remove its secure connection prefix, or disable certificate checks to work around the error.

If the response contains a web page instead of a configuration, you may have copied a panel page URL, a network sign-in page may have replaced the response, or the client may have retrieved an error page. If the error says the format can't be parsed, check that you're using the subscription import option—not a file import or a different configuration format. Clients don't all use the same configuration syntax. Content readable by one tool isn't necessarily compatible with every platform.

An expired account, unusual data status, or a reset subscription may also affect configuration retrieval. Use the panel status and error message as your guide; old server names left in the client don't confirm your account entitlements. Monthly subscription data resets on the activation date each month. Data add-ons are available until used and never expire. For current pricing and billing details, see the plans page. If the panel status doesn't match what you expect after payment, save the order status and contact support through a ticket.

Keep Your Existing Configuration While Troubleshooting

If possible, add a new configuration and test it rather than overwriting one that still works. After confirming the new configuration shows the expected routes, connects successfully, and uses the right rules, you can clean up the old one. If the client only allows replacement, use its local backup feature first and store the backup securely. Backups may contain subscription links and account information, so don't upload them to public cloud storage or share them.

If an update succeeds but the route list looks unchanged, the list may not need updating, or the client may still be showing a different configuration. Check the active configuration name, status, and update result instead of importing repeatedly. If you accidentally imported several similar configurations, label their sources, confirm which one is active, then remove duplicates. You can organize configuration names, but don't put subscription keys in names or screenshot titles.

Update as needed based on panel notices, route changes, and your usage; there's no need to update every time you open the client. Whether automatic updates are available and how they work depends on the client and system background policies. For a complete explanation of retrieving, importing, and resetting subscriptions, see the Complete Guide to Subscription Links. For your first import, follow the setup guide.

For a failed-update support ticket, include the client name, platform, import method, exact error, account status in the panel, and whether existing routes still work. Don't include the full subscription link in the description or a log screenshot. If support needs to verify your account, provide only the minimum necessary information through your signed-in ticket. Don't routinely include usernames, passwords, or subscription credentials with diagnostic details.

Apps Not Using the Proxy and Mobile Disconnects in the Background

Apps May Use Different Network Paths

If a browser works but one app doesn't, first check whether that app follows the system proxy. System proxy settings usually affect programs that read them; they don't automatically cover every process. Some apps have their own proxy settings, while others may require a client mode that handles more network traffic. Read the client and app documentation before choosing a method. A working browser doesn't mean every app is using the same exit.

A client's virtual network interface mode may need additional system permissions and can conflict with workplace network tools or other network extensions. Save your current configuration and make sure you can restore the original mode before enabling it. Test the same app afterward. If the app has its own proxy settings, avoid configuring conflicting addresses in both places. On a managed device, follow your organization's rules and ask an administrator for help when needed rather than bypassing device policies.

Routing Rules Need to Cover an App's Dependencies

An app may use different domains for sign-in, content, uploads, and notifications. Routing the main domain through the proxy doesn't guarantee that every dependency matches the same rule. Check the client's connection log to see whether failed requests matched a direct or proxy rule, then decide whether the rules need updating. Don't add every unfamiliar domain in the log to the proxy list; some may be local services, update checks, or unrelated requests.

After changing modes or exits, fully quit and reopen the app so existing connections don't keep using the old route. End active uploads, calls, or submissions first. If the app still shows a region or account message, check the destination service's own terms; network routing can't change account eligibility. For delayed notifications, also consider system push delivery and background scheduling. Notification timing alone doesn't test route connectivity.

If it fails when locked, check system background management

When a mobile device is locked, the system may restrict background activity, switch internet connections, or suspend the app. First compare performance with the screen kept on, then check whether the client connection actually drops after locking. On Android, review the client's battery optimization, background activity, and network permissions. Menus vary by device, so follow the system's instructions. Don't grant unrestricted background access to every app just to troubleshoot.

On iOS, check the system's connection status rather than relying on whether the client is still visible in the app switcher. If the connection acts up after switching Wi-Fi, waking the screen, or using another network configuration, reconnect and see whether the issue can be reproduced. Don't repeatedly remove system configurations; this can erase the original authorization state and useful diagnostic clues. If you have other network tools installed, check which configuration is actually active.

If only one app fails in the background but works again in the foreground, check that app's background permissions and the system's data-saving settings. A working client tunnel doesn't grant an app permission to run in the background. If every app loses access after the screen locks, check the client process, system connection status, and internet connection first. Keeping these issues separate can prevent you from repeatedly rebuilding a subscription to fix an app-specific problem.

In your ticket, include the app name, how foreground and background behavior differ, whether locking the screen or switching networks triggers the issue, and whether reconnecting the client restores access. Screenshots of system permission settings can help, but hide other apps and personal information. For workplace software or private work content, describe only the network behavior and necessary domains. Support generally doesn't need your full work screen or the app's sign-in credentials.

DNS Issues: Check Resolution and Exit Routes

Separate DNS Lookup Problems from Connection Failures

DNS translates domain names into addresses used to connect. A browser's “can't resolve domain” error usually means the problem occurs before a request reaches the destination service. A timeout may mean an address was resolved but the connection failed later along the route. Don't assume a blank page means DNS is at fault. Save the exact error first, then compare whether multiple domains are affected and whether results change when the client is on or off.

Desktop users can use system tools to check whether a DNS lookup returns a result. The command below queries a domain used for demonstration and contains no account information; it doesn't automatically repair your network. A successful lookup only means the query received a response, not that the website itself will work. A failed lookup needs to be considered alongside your network environment, system policies, and whether the tool is available. Don't hard-code an address returned for one website into a permanent configuration.

nslookup example.com

Some systems offer other lookup tools, but command-line utilities, browsers, and clients may use different DNS paths. A browser may have secure DNS enabled, a client may handle names for proxy requests separately, and the system cache may hold old results. First identify which layer you're checking, then compare. Treat tool output as a clue, not a definitive account of the path your browser used.

Check DNS Settings in Your Browser and Client

If only one browser reports a domain error, check its secure DNS and proxy extension settings. Work or campus networks may require specific DNS policies; don't switch to an address recommended online without approval. You can temporarily restore the browser's original or system-default DNS setting for comparison, and note the original value before changing anything. If the issue occurs only on one exit, test another exit without changing browser settings. That's easier to diagnose than changing several DNS servers at once.

If the client has options for remote DNS resolution, domain-based routing, or virtual addresses, leave the subscription defaults in place where possible. Different modes affect how domain names reach the exit and what addresses apps see. If you're unsure what an option does, don't copy configuration snippets from another client's guide, especially unfamiliar DNS addresses or rules. A setting being accepted by the client doesn't mean it works with your existing routing logic.

Caches, Encrypted DNS, and Local Resources

After changing DNS settings, old connections and cached results may still affect what you see. Fully quit the app you're testing, reconnect the client, and try again. Clear the cache only when necessary, using your system's official instructions. Don't run network reset commands from unknown sources. If your device relies on internal domains, printers, or a work network, confirm how to restore them first. Otherwise, you could fix international websites while losing access to local resources.

DNS leaks concern whether DNS requests follow the expected path—not just which exit address a website displays. Your browser's exit and system DNS may use different mechanisms, so a single website's test shows only part of the picture. Check your current exit at My IP, then compare it with your client settings and DNS behavior. Exit information alone isn't a complete privacy check.

“Anonymous, no logs” is VPNPut's privacy claim; it doesn't mean browser extensions, destination websites, or other software on your device won't process data. Keep that distinction in mind when troubleshooting DNS: a route service and the privacy of your entire device are not the same thing. For more on verifying claims and minimizing data, read the Guide to Verifying No-Logs Claims and review the Privacy Policy.

If DNS returns a result but you still see a certificate warning, don't proceed to the website or disable certificate checks. Check the system clock, public Wi-Fi sign-in status, and domain spelling; if needed, test on another internet connection. A certificate issue could involve network redirection or the destination site's configuration, so changing DNS alone won't identify the cause. For sign-in and payment pages in particular, make sure the secure connection is valid before entering account information.

For a DNS support ticket, include the affected domain, browser error, client mode, and whether browser-specific DNS is enabled. Attach redacted command output if relevant. It may reveal local network names, DNS servers, or private network addresses, so check it before sharing. Support needs the before-and-after comparison and error type—not a full system network inventory. If only an internal work domain fails, contact your network administrator too.

Device Alerts, Account Status, and Support Tickets

A Device Limit Warning Doesn't Mean Your Plan Has a Device Cap

VPNPut allows unlimited simultaneous devices. If a client reports that you've reached a device limit, note which app or service displayed the message. It may come from a third-party client's account system, the destination website's device management, or a different subscription—not the VPNPut plan. Don't delete other devices or make another payment until you know what the warning refers to. Check the active configuration and signed-in account to identify where it came from.

Unlimited devices doesn't mean your account or subscription should be shared publicly. The more devices you use, the harder it is to manage old configurations, incorrect passwords, and exposed links; simultaneous transfers also use your account data. When replacing or losing a device, check whether it still has your subscription and sign-in details. If credentials may have been exposed, use the management options in the panel. For account security basics, see the Guide to Protecting Your Account and Subscription.

Tell Billing Issues Apart from Network Issues

If you can't use your account, check the order, plan status, and data balance first. Don't rely only on a payment app's charge notification. A completed payment and an order confirmed in the panel are separate steps; if the statuses don't match, contact support through a signed-in ticket. VPNPut accepts Alipay / WeChat Pay / USDT. If you share a payment screenshot for verification, hide unrelated account and transaction details. Never send your payment password or a complete personal statement.

Choose a plan based on the data you actually need. Monthly subscriptions cost ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated for the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. See the plans page for a full comparison. Changing plans isn't a universal fix for connection problems.

Write a Reproducible Support Ticket, Not a Pile of Screenshots

Start with one sentence describing what you expected and what actually happened. Then include your setup, steps to reproduce, the exact error, and checks you've already tried. For example: your basic connection works and the subscription updates, but one domain times out on a particular exit while other exits work. That can already narrow things down. If you can't run every test, say so. There's no need to keep reinstalling or changing settings you don't understand just to submit a ticket.

Symptom:
Expected result and actual result:
Time and time zone:
System and client:
Connection type:
Current route and connection mode:
Steps to reproduce:
Results on other routes or networks:
Exact error message:
Steps already tried:
Attachments: redacted screenshots or relevant logs

Logs should cover relevant events before and after the failure, in chronological order. A screenshot showing only the final “failed” message may miss the real upstream cause. Uploading an entire long-term log can expose private domains and account details. Before sending, search for usernames, subscription links, authorization fields, and private page content. Hide sensitive information but keep the error type. Redacting route names, failure stages, and timestamps removes the details needed to diagnose the issue.

Contact support directly if your panel status doesn't match a completed order, your subscription can't be fetched on different networks, routes in multiple regions keep failing despite a working basic connection, or the checks on this page haven't identified the issue. For problems limited to a destination site's account eligibility, workplace network policies, or device hardware, check with the relevant service or administrator as well. Support can help identify where the issue lies, but can't replace a third party's account review or device maintenance.

Refunds and troubleshooting are separate matters. VPNPut offers a 30-day money-back guarantee; see the Terms of Service for details. To request a refund, state that clearly in a ticket through the panel—you don't need to bury your request under a long log. If you'd also like to keep troubleshooting, you can describe a reproducible issue. Don't put account matters on hold while waiting for test results. The panel record determines how an order is handled.

After receiving advice, follow it one step at a time and report the result of each step. Keep the configuration you had before making changes. Once the issue is resolved, confirm that your usual routing mode, local resources, and everyday apps all work, then remove any extra test configurations. The goal isn't just to make one website load temporarily; it's to leave your system in a state you understand and can restore. If the same issue comes back, your comparison notes can help you quickly determine whether it's the same problem.