Confirm the network outage
If multiple services fail, compare the assigned address, hostname and console before editing guest network settings.
Verify the assigned address in your authorised VPS or client view and compare it with the affected hostname; wrong DNS can mimic network failure. Note onset, affected hosts, intermittency and whether another connection has the same problem.
If only SSH fails while the website still answers, use the separate SSH refusal-versus-timeout guide. If the VPS is stopped or has a boot error, investigate that state first. Avoid changing DNS or restarting the server merely because one browser request failed.
Gather guest and panel evidence without changing network settings
If an authorised console is available, check whether the guest has reached a login prompt and record any visible network error. A console can remain accessible while the guest has no usable external network. An authorised operator may compare the guest interface address and default route with the assigned network configuration; Ubuntu documents these as separate settings, and a temporary address command is not a durable repair. If you do not have guest administration permission, send the console symptom to the operator instead of running commands.
Record whether a direct request to the assigned public address and a request to the intended hostname fail in the same way, but remember that virtual-hosted websites may not respond correctly to a bare IP. Do not post console screenshots containing credentials, private addresses or customer data to a public forum.
Illustrative split: console login works while HTTPS and SSH both fail from two networks. Record address, route and firewall observations through an authorised route, then ask the operator to identify the failing layer.
A bare-IP HTTP test can fail because the site requires a hostname; compare protocols and Host or TLS name before calling the network down.
Ask for a scoped network investigation
Send support the VPS identifier, assigned address as shown in the authorised panel, first failure time, affected services and any safe console observation. Virtualizor lists provider-side blocking, firewalls and whether the VPS actually booted among network checks. Those checks span the guest, virtual network and upstream provider; a customer-visible failure alone does not identify which layer is broken. Under VM Start with Managed OS, Novasean supplies agreed OS and VM work while the customer retains root access. Agree who changes the affected network setting. Ask the operator to preserve the last working configuration and explain the proposed change before applying it.
Do not use a network reset, firewall disable, OS reinstall or repeated power cycle as a diagnostic shortcut. Each can remove evidence or increase downtime while leaving an upstream fault untouched.
Verify recovery and keep a rollback route
After the operator reports a repair, test the intended HTTPS hostname and at least one other agreed service from an independent connection. Compare the panel-assigned public address with the one now in use and record when access returned. If only one service recovers, report that split result: the remaining fault may be service-specific. If connectivity drops again, give the operator the time and previous change reference so they can review or roll back the scoped configuration.
Frequently asked questions
Does a working console prove the network is healthy? No. Console access reaches the guest through a separate route; it does not prove the guest has the right address, route or external connectivity.
Should I change DNS to another address? Only after the service owner confirms the correct destination. A DNS change cannot repair a VPS that cannot use its assigned network.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.