VPN Troubleshooting Guide

Connection setup / Establish a baseline

Can't connect at all? Check your local network first

“Can't connect” can mean the client won't start, the connection handshake failed, or the destination website isn't responding. Describe exactly what happens: Does the button change to Connecting? Does it quickly return to Disconnected? Is there a specific error? Does the same thing happen on every route? A status in the app only shows how far the client has progressed; it doesn't prove the connection is usable. Don't delete the client or clear its configuration yet. The original error and existing settings are often more useful for troubleshooting than a fresh install.

Check whether your internet connection works

Disconnect from the proxy and make sure no manual system proxy is still enabled. Then open a website you can normally access directly. If that fails too, check whether you've completed Wi-Fi sign-in, whether your Ethernet cable is connected, and whether the network requires you to accept terms in a browser. A public network may show as connected while still waiting for authentication. Complete the network's legitimate sign-in process before testing the client; don't mistake an offline internet connection for a route problem.

Once direct access works, keep the device and client unchanged and test on a different trusted network—for example, switch from your current Wi-Fi to another network. After switching, check that the default route has updated, then reconnect to the same route. If the issue occurs on only one network, investigate that network first, but don't assume you've identified the exact restriction. A general description of the network is enough; don't share your router's admin address or full network configuration.

Narrow down the issue by the error stage

If the client says there's no configuration or no available routes, go to the subscription update section instead of repeatedly tapping Connect. For an authentication error, check that the plan in your account panel and the client subscription belong to the same account. For a connection timeout, keep the current settings and compare with a route in a different region. Change one thing at a time: don't change the route, mode and DNS together, or you won't know which change fixed the issue.

If only one route fails, use a working route temporarily and note the failed route and time. If every route fails, check system proxy permissions, network extension authorization and possible conflicts with other networking software. A work-managed device may restrict network extensions; ask the device administrator about those restrictions rather than removing management settings. Read desktop security warnings carefully instead of dismissing them or leaving protections disabled.

Check the time, permissions and active connections

A system clock that's significantly off can cause certificate verification to fail. Check automatic time and time zone settings, correct them, then reconnect. If an error mentions a port conflict, quit other proxy clients and try again; only one app should manage the system network at a time. Don't terminate unfamiliar system processes or change the routing table without a clear reason. If the client needs to install a network component, follow the instructions in your account panel, grant the required permissions and check that the system hasn't blocked the component.

To check whether a client has really quit, look in the system tray or menu bar—not just at the main window. Some apps keep a background service running after the window closes, and its previous network takeover can affect later tests. After quitting, check whether the system proxy has been restored. If it hasn't, note the original manual proxy settings before disabling any obsolete entries. Don't change settings managed by your organization; tell the administrator that the client is closed but network traffic still points to the old proxy.

When to stop making local changes

Submit a support ticket if your internet connection and account are working, your subscription updates successfully, but routes in different regions still fail at the same stage. Include the original error, network type, routes tested and any recent changes to networking software. If the same configuration works on another network, include that comparison too. These details help support distinguish between a route entry point, your network and client permissions—without asking you to repeat unrelated steps.

After connecting / Websites & DNS

Connected but websites won't load? Check DNS and proxy routing

If the client shows Connected but websites won't load, separate the issue into DNS resolution, request routing and the destination's response. First check whether all websites fail or just one domain, and whether the problem affects only your browser or every app. Note the browser's exact error, such as a name resolution failure, connection timeout or certificate warning. Each points to a different stage. Don't replace your entire configuration just because a page is blank, and don't mistake restrictions on a website account for a network connection issue.

Check whether the request reaches the client

Open the client's connection log or rule-hit log, then reload the page. If nothing changes in the log, check the system proxy, browser proxy extensions and whether the client is running in manual mode only. A separate browser proxy may bypass the system proxy. For troubleshooting, choose one way to route traffic, quit duplicate proxy extensions and test the same page again to avoid conflicting settings.

If the destination domain appears in the connection log, check whether its traffic is routed directly or through the proxy. In rule mode, some requests may go direct by design; that doesn't mean the client has failed. You can temporarily switch to Global mode for comparison, but whether it covers a particular app still depends on whether that app uses the client's routing interface. Restore your normal mode after testing and note the matching rule name—not just that “Global mode worked.”

Tell a DNS failure from a connection failure

DNS translates domain names into addresses. If resolution fails, the connection hasn't started yet; a successful lookup doesn't guarantee that the destination is reachable. On desktop systems, use the command below to check basic name resolution. The example domain is for demonstrating the command only—not a subscription address. The DNS server, returned address and error text can help with comparisons, but a lookup isn't a speed test and can't tell you which region a streaming service will show.

nslookup example.com

Some clients handle DNS internally, and browsers may use Secure DNS, so a system command and browser request may follow different paths. If the command succeeds but the browser fails, check browser settings and the client log. If both fail, disconnect the proxy to see whether basic name resolution returns. Don't change DNS to a public address without understanding the issue; a new resolution path may not suit your network and could make troubleshooting more complicated.

Use cache clearing only when there's evidence

After changing DNS settings, close and reopen the affected app so it doesn't keep using an existing connection. Refresh the DNS cache only if there's evidence that the system cache is involved, and follow your operating system's instructions. Browser cache, DNS cache and website sign-in state are separate things; don't clear all browsing data as a first step for a network issue. A private window can help compare the effects of extensions and sessions, but it may still use the same system network settings—it isn't a separate network.

Don't leave certificate verification disabled to get past an error. Public Wi-Fi sign-in pages, device management policies or an incorrect system clock can all affect certificates. First check that the domain is spelled correctly, then check the time and network sign-in status. If a certificate warning appears only on one network, don't enter sensitive information. Share the certificate error name with your network administrator or support; don't install an unfamiliar root certificate.

Report results by troubleshooting layer

When submitting a ticket, include the destination domain, browser error, whether system DNS resolution worked and whether the client logged the request. The domain alone is usually enough; remove sensitive session parameters from the full URL. For more detailed checks, see the guide to checking your exit IP, DNS and per-app routing. These results are more useful than “it says connected, but nothing works” and can reduce back-and-forth.

Connection performance / Route comparison

Slow speeds and peak-time lag: compare each part of the connection

Slow performance can show up in several ways: websites take a long time to open, downloads remain slow, videos buffer repeatedly or interactive apps occasionally freeze. Start with the symptom that affects you most; don't label everything “high latency.” Connection handshakes, DNS lookups, sustained transfers and the destination service can all play a part. A latency test in the client reflects specific test conditions; it doesn't directly measure video performance or replace testing the app you actually use.

Set up a repeatable comparison

Keep the device, network, client mode and destination the same, then change the route. For video, use the same clip and resolution; for downloads, use the same source. Pause large transfers on other devices. If you change the website or video quality while switching routes, the results aren't comparable. Weak Wi-Fi, a busy router and local sync tasks can make every route seem slow.

First compare content that works over a direct connection to see whether your internet connection has slowed, then compare the destination that requires a proxy. If both direct and proxy connections are slow, check the network and device resources first. If only one route is slow, switch to a different route. If several regions are slow only for the same website, the cause may be the website, its content delivery network or an account restriction. Don't conclude that the whole subscription is unusable based on a single destination.

For peak-time issues, note when they happen

To investigate peak-time lag, check whether performance changes under the same conditions at different times. Note your local time, time zone, route name and target app; there's no need to run speed tests continuously. If it's normally fine but repeatedly slows at certain times, congestion may be worth investigating. That alone can't tell you whether it's on your local network, at the route entry point or at the destination service. Support needs the time and region to compare reports in context.

At the same time of day, you can compare routes in different regions or routes of different types. A nearby location isn't necessarily faster: the actual path, your network provider and the destination's location all affect performance. Don't choose by flag alone or assume one region is best for every app. A route label indicates an available exit location, not whether it suits your current destination; check the connection log and actual performance. For more on choosing a route, see the guide to global locations and routes.

Don't conflate bandwidth, responsiveness and video quality

A video player may automatically change quality or keep using a connection established before you switched routes. After switching, reload the content and check whether it still buffers. Download software may limit transfer speeds, and cloud storage may impose account-based limits; switching routes repeatedly won't help. If websites open slowly but downloads are fine, focus on DNS, connection setup and page resources instead of chasing a higher speed-test result.

Don't change MTU or disable system networking features without evidence. Some networks can have path compatibility issues, but you need symptoms such as large requests failing while small ones work to investigate that. Applying settings you found online can cause new connection problems. If only uploads, long responses or particular content types are affected, tell support exactly what works and what doesn't before trying a reversible change they recommend.

Check data allowance and speed separately

Also check your remaining data and plan status in the account panel. Monthly subscription data resets each month on your activation date, not on a shared calendar-month schedule. Data add-ons don't expire and remain available until used. See the plans page for available options. These are data allowance rules, not speed guarantees. If your allowance is available and peak-time problems keep recurring, include the time, route comparison and basic network performance in your ticket. There's no need to send a large collection of speed-test screenshots that can't be compared.

Connection stability / System lifecycle

Frequent disconnects and mobile background dropouts

First work out whether the client actually disconnected or only an app session ended. If the client still shows Connected and other websites work, but a chat or coding tool stops responding, the app's persistent connection may not have recovered. If the system VPN indicator disappears and the client shows Disconnected, the issue is more likely at the system or connection layer. Each case needs different details. Don't treat every sign-in prompt as a route disconnection, and don't rely on the system icon alone to confirm an app request succeeded.

Look for what happens just before a disconnect

Think about whether the issue always follows locking the screen, switching Wi-Fi, putting the device to sleep, enabling battery saver or leaving the client. A network switch changes the local address and route, so existing sessions may need to reconnect. After waking the device, first confirm the internet connection is back, then check whether the client reconnects automatically. If the same action triggers the issue each time, describe it; that's more useful than simply saying “it disconnects while I'm using it.”

Compare foreground and background behavior once: keep the app open and confirm it works, then lock the screen or switch away and check the client status and app log when you return. Don't change routes or battery settings at the same time. If it works in the foreground but fails in the background, check how the system manages background activity. If it fails in both, compare routes and networks. Before recording your screen, hide notifications, account names and subscription URLs.

Android: Check battery and background restrictions

Settings names vary between devices. Look in the app's settings for battery use, background activity or auto-start management. First make sure the client is allowed to run in the background, then check whether the system closes it when the screen locks. Apply changes only to the client; you don't need to disable the system-wide power-saving feature. If the device is managed by a work profile, check with your administrator whether its policy allows personal network connections to remain active.

Some systems offer an always-on VPN option or a setting that blocks connections outside the VPN. Read the description before enabling either: these settings may stop other network requests if the client hasn't connected or can't recover. They aren't general fixes for disconnects. If one is already enabled and the entire network stops working, note the original setting and check the client's instructions before changing it again.

iOS: Check network extensions and configuration conflicts

Check whether other VPN configurations remain on the system and whether the enabled one belongs to the client you're using. Other network extensions or on-demand connection settings may affect which app handles the connection. Quit clients not involved in the test, then authorize the current connection again. Don't remove an unfamiliar device management profile; ask your administrator about profiles on a managed device. If a system update prompts you to authorize the extension again, check the details in the prompt.

iOS Background App Refresh and VPN network extensions are separate mechanisms, so enabling Background App Refresh may not fix disconnects. Note whether the system VPN status changes and whether reopening the client restores the connection automatically or requires you to reconnect. If only the destination app stops receiving content while the network extension remains active, check the app's background behavior and persistent connection recovery instead of reinstalling the VPN configuration.

Desktop sleep and persistent connection recovery

On Windows, macOS and Linux, the network interface may take longer to recover from sleep than the app. Wait for the network to become available, let the client reconnect, then restart the task. For terminal streaming output, remote sessions or AI code completions, the app may need to establish a new session even after the network recovers. Don't repeatedly send the same task before you know what happened, or you may trigger duplicate actions.

If routes in different regions all disconnect after the same screen-lock action, focus your report on the device and system comparison. If it happens only on a particular route and isn't linked to screen locking, include the route name and time. If the client crashes, save the error message and any useful logs before updating or reinstalling. Reinstallation can erase evidence, so it shouldn't be the automatic first step every time you disconnect.

Configuration source / Account & sync

Subscription update failed? Check your account, URL and format

A failed subscription update isn't the same as a failed route connection. The subscription provides configuration to the client; routes use configuration the client already has. The client may still use an old route even if it can't reach the update endpoint. Or the subscription may have updated successfully without changing the selected route. First identify whether the error happened while fetching, parsing or saving the configuration. Then check the account, network or client compatibility as appropriate.

Verify the source in your account panel first

Open the account panel and check the account and plan status. You must be signed in to get your subscription. Use the corresponding entry in the panel, not an old URL from a chat that you can't verify. InnVPN doesn't require an email address; accounts use a username and password. If you have more than one account on the device, check which one you're signed into so you don't mistake a mix-up for a configuration problem.

Once your plan is active, copy or import the subscription again as described in the panel. Check for spaces, line breaks or non-English punctuation; don't guess at or edit URL parameters. A full subscription URL is sensitive. Don't paste it into a public website, online conversion tool or group chat to test it. If support needs to investigate, describe the error and the entry you used. Confirm what information is needed in a ticket before sharing anything.

Check the error type

If fetching the subscription times out, first check whether the device can reach the account panel and whether an old proxy setting is affecting the update request. Some clients let you choose a separate connection method for subscription updates; follow the client's instructions to compare direct access with your current proxy. Don't disable all system protections. If you get a sign-in or network authentication page, the client usually can't parse it as a route configuration. Complete sign-in or network authentication first.

For a parsing error, check whether the import format matches your client. Don't paste an entry intended for another configuration format or just change the file extension. If the client reports unsupported fields, keep the exact error and check the panel's instructions for that client. Format support depends on the client implementation. This page doesn't provide a fixed version number or generic replacement template that might not match the service.

Keep the old configuration while testing the new one

If the old configuration still works, don't delete it first. If the client allows, keep it and import the new configuration as instructed in the panel. Switch only after confirming that the route list appears. “Added,” “updated” and “enabled” may be different states: having a new configuration doesn't mean it's the one currently running. After switching, check the active configuration name and selected route so you don't mistake an updated-looking screen for a working new configuration.

If you've edited traffic-routing rules manually, a subscription update may overwrite some of them or fail to merge with your local changes. First export a settings record that contains no sensitive information, then identify which settings came from the subscription and which you added yourself. Don't send someone your entire configuration file to edit. For comparison, try the original configuration from the panel. Once the basic connection works, restore only the local rules you actually need.

Data allowances, upgrades and updates are separate

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on your activation date. Mid-cycle upgrades are prorated based on the days remaining. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Check these details to verify your account status. They don't tell you the subscription URL format, and repeated updates aren't a substitute for checking your data allowance.

If the panel shows the correct status, you're using the original import method and the same parsing error persists on different networks, submit a support ticket. Include the client name, operating system, exact error, whether you edited the configuration and whether the old configuration still connects. Don't include the full subscription URL. For first-time setup, check the import steps in the quick start guide. For unfamiliar terms, see the quick reference to subscription and routing terms.

Request routing / Apps & rules

One app won't use the proxy? Check traffic routing

A browser that works doesn't mean other apps use the same proxy. An app may use system settings, its own networking library, environment variables or a separate proxy configuration. First identify whether the issue affects the web app, desktop app, terminal tool or mobile app, then check the client's connection log. If the target app doesn't appear in the log, investigate how its traffic is routed. If it does appear but the request fails, check the rules, route and destination response.

Understand mode names and what they actually cover

Smart routing typically uses rules to send traffic direct or through the proxy. Global mode typically changes the routing of requests that reach the client. Direct mode sends relevant requests without a proxy exit. Exact behavior depends on the client. “Global” doesn't necessarily mean that every process on the device is covered. If a program doesn't use the system proxy at all, switching to Global mode may make no difference; check whether the client offers a way to capture that program's traffic.

For troubleshooting, start in rule mode, open the target app and check which rule matches its domain or process. If it matches a direct rule but needs a proxy, try Global mode temporarily to see whether routing changes the result. Once you've confirmed that, restore rule mode and adjust the relevant rule in a way the client supports. Don't permanently delete all direct rules to fix one app; sign-in, payments and access to local devices may depend on the existing routing setup.

Check desktop apps and terminal tools separately

Terminal tools often read environment variables when they start. A terminal or editor that was already open may still use old values even after you change system settings. Check whether the variables exist, then verify that their local proxy endpoint is still provided by the running client. There's no fixed port here because it varies by client and configuration; use the value shown by your client. Don't enter a route's server address as an app's local proxy endpoint.

# macOS / Linux: View common proxy variables in the current terminal
printenv HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

# Windows PowerShell: View proxy variables in the current process environment
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

Don't expose variable values that contain authentication details. If a variable points to a client you've already quit, note it before removing the obsolete setting, then reopen the terminal and test again. Tools vary in whether they support uppercase and lowercase variable names; check the documentation for the tool you're using. Also check exclusion lists: a destination domain marked for direct access may bypass the proxy. A working browser doesn't rule out a process-level configuration issue.

AI tools: Separate request issues from account restrictions

AI coding tools may use separate sign-in pages, completion services, extension marketplaces and terminal commands, so testing just the home page isn't enough. Identify whether the failure occurs during sign-in, request submission, streaming output or plugin access. If the website works but the editor doesn't, check the editor's proxy settings and plugin process first. If completions stop but regular pages work, save the error and connection log from the interruption and describe the persistent connection behavior instead of just saying it's slow.

If the destination service shows a region restriction, account verification, quota warning or permissions message, follow that service's policies; switching routes can't replace account eligibility. InnVPN provides network connectivity and doesn't guarantee account approval or feature availability on other platforms. For guidance on your options, see the ChatGPT acceleration guide. For development, continue with the guide to choosing a VPN for AI coding.

Streaming apps need a fresh session

Video apps may cache region checks or use different domains for pages and playback resources. After switching routes, reopen the content and check whether the requests in the client log change. If the catalog is visible but playback fails, keep the playback error code and distinguish content licensing, account region and network errors. Don't claim that all content has been tested just because the home page opens, and don't assume a region name guarantees a particular result.

If only one app is affected, include its name, how you accessed it, the stage where it fails and the matching rule in your ticket. Keep the error code visible in screenshots but hide account information. Before adding a domain- or process-specific rule, ask support to confirm what your client supports. For streaming-related checks, see the streaming connection guide; the destination app's actual response is what matters.

System differences / Multi-device status

Platform permissions and device-limit warnings

InnVPN supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. If a client shows a “device limit exceeded” warning or similar message, don't assume it's a plan restriction. First check whether it came from the InnVPN client, system VPN settings or the destination website's account page. These limits aren't interchangeable. Identify the source before taking action so you don't change plans or remove a device unnecessarily.

When comparing devices, first check they're using the same account

If one device connects and another doesn't on the same network, start by comparing their configurations. Check that both use a valid subscription from the same account, that the current configuration is enabled and that the same route is selected. Don't rely only on the green status on the client's home screen. Once the account and subscription source match, compare system permissions and proxy modes. This separates service-side issues from device-side ones without resetting every device at once.

Unlimited devices doesn't mean every device uses the same steps, or that routers, shared networks and destination platforms support unlimited sessions. A destination app may have its own account device policy, and a local router may limit connections or resources. If a third-party service shows the warning, check its account policy. If the warning comes from the InnVPN panel or client, keep the exact wording and submit a ticket; don't infer a device limit that hasn't been stated.

Check for leftover settings on desktop systems

On Windows, the system proxy and proxy settings used by some services may differ. A working browser doesn't mean background tools work too, and a failed background tool doesn't prove the system proxy is broken. Start with the target program's actual network settings, then check for an old proxy or startup entry. Don't run network reset commands you found online without understanding them; they can affect work-managed settings, virtual network adapters and other services in use.

On macOS, check the proxy settings for the current network service and network extension permissions. Switching Wi-Fi networks, using a wired connection or installing other networking software can change which service handles traffic. If the system asks you to approve an extension, check its source; on a managed device, ask your administrator first. On Linux, distinguish desktop settings, shell environment and the system's DNS resolver. Note the current configuration before troubleshooting, so a command for one distribution doesn't override another network management setup.

Understand installation and subscription access separately

Get the client from the download section in the account panel. Sign in to download on Android, Windows, macOS and Linux; iOS availability depends on the active plan shown in the panel. Having an installation link doesn't mean you have a valid subscription, and importing a subscription doesn't mean system permissions are complete. If the download or permissions fail, say exactly which step you're stuck on. Don't lump installation, subscriptions and connection issues together as a download failure.

If you're having trouble with the store region, configuration permissions or getting an iOS client, see the iPhone VPN setup and selection guide. Don't install a client from an attachment with an unverified source, and don't delete a device management profile as if it were a regular VPN configuration. Before updating or reinstalling, make sure you can still get your subscription from the panel and note any local rules so you can restore them later.

How to describe a restriction warning

In your ticket, say which page shows the warning and whether it appears during sign-in or connection, and note whether other devices work. You can attach a cropped screenshot showing the warning title and error while hiding personal information in device names. Support needs to identify where the warning came from and check your account status—not collect every device identifier. If devices behave differently, summarize the operating system and result for each one; don't upload every configuration file.

Restore settings / Handoff to support

Wrap up troubleshooting and prepare your support ticket

The goal is to restore normal use and record results you can explain—not to try every toggle. If a change fixes the issue, note what worked and undo unrelated test changes. If the issue persists but you've checked your network, subscription and routes, hand it over to support. Randomly changing more settings can bury the original symptom under new problems and make it harder to diagnose.

Summarize the steps so the issue can be reproduced

Describe what happened from normal to abnormal: the device and network, the client you opened, the mode and route you chose, the action you took and the message you saw. Use the exact wording shown in the interface. Don't group a connection timeout, authentication failure and region restriction under “it doesn't work.” If there's no error message, describe what you observed—for example, the page keeps loading, the system VPN indicator disappears or the client closes unexpectedly.

Include only comparison results that help answer the question. Did the same route work on another network? Did another route work on the same network? Did other apps work? Was there a difference between foreground and background use? These details are usually more useful than a large pile of screenshots. List the steps you've already tried so support won't ask you to repeat them. If a change wasn't reverted, say so, so the next recommendation starts from the current setup.

Details you can copy into a support ticket

This checklist doesn't ask for account credentials. Use the system information shown on your device; don't guess the version or copy a full hardware report. Include the time zone with the time, and describe the network generally—for example, home Wi-Fi or a work network. A domain is usually enough for the destination. If only a particular page fails, remove sign-in tokens, session parameters and personal information first, then describe what the page is used for.

What happened:
Device and operating system:
Client name:
Time and time zone:
Network type:
Current mode and route name:
Exact error or cropped screenshot:
Do other websites or apps work?
Result after switching networks:
Result after switching routes:
Settings recently changed:
What you'd like us to check:

If support requests logs, first check whether your client can export them for a specific time range. Logs may include destination domains, local addresses or account-related fields, so review them before sharing. Include only the relevant lines around the issue; don't upload your full browsing history by default. If you're unsure whether a field is sensitive, ask in your ticket which fields are needed. Don't zip and send the entire configuration folder for convenience.

When to contact support promptly

Submit a ticket if your account status doesn't match your entitlements, the original subscription can't be parsed on different networks, routes in different regions all fail at the same stage, or the panel shows a device restriction that conflicts with the unlimited-device policy. If the client crashes or network component permissions fail, keep the warning and contact support. If the issue occurs only on a work-managed network, you can also ask your administrator about local policy, but don't remove management settings yourself.

If only a destination platform shows an account eligibility, content licensing or payment restriction, follow the platform's instructions first. A network service can't override third-party account rules or guarantee access to content in every region. Support can help check request routing and connection behavior, but third-party account approval isn't a route issue. Keeping those responsibilities separate helps focus on what can actually be verified.

Undo temporary changes after recovery

Once the connection is working again, restore your usual routing mode and undo temporary DNS or app settings used for comparison. Then check your commonly used apps. If you paused other networking tools, restore them one at a time and watch for the issue to return. Don't re-enable everything at once or you'll have the same difficulty identifying a conflict. Keep a note of where the working configuration came from and its key settings; don't save a full subscription URL in ordinary notes.

InnVPN offers a 14-day no-questions-asked refund. See the Terms of Service for how to request one. Payment methods include Alipay / WeChat Pay / USDT. Plan details are listed on the plans page. Describe connection and billing issues separately in your support ticket; don't create extra accounts just to keep testing. If the same issue comes up again, refer to your earlier ticket and note what changed—it's usually clearer than starting from scratch.