Quick answer: locate the first layer that fails
If an application works on the VPS but not from another network, do not assume its port merely needs opening. Confirm the exact hostname or assigned IP, protocol and port; check whether the application listens on the guest; then test the guest firewall, any container publication and any upstream network control that your accepted service actually includes. A listening process bound only to 127.0.0.1 is deliberately local. A firewall allow rule cannot make it reachable from outside.
This guide concerns a customer-authorised application port on a Novasean VPS. It does not promise that every order includes a customer-facing firewall control or that Novasean manages the guest application. Keep administrative interfaces, databases and development servers private unless a reviewed access design requires otherwise.
Write down the endpoint and intended audience
Record the application name, expected transport (TCP or UDP), destination port and the exact public IPv4 or IPv6 address or hostname. Check that the hostname resolves to an address assigned to this VPS; a stale DNS answer sends the test to a different machine. Decide whether the service should be public, restricted to named client addresses, reachable through a reverse proxy or available only over a private network. Use the application’s own protocol for the test; a browser cannot establish whether a non-HTTP service works.
If the VPS has no working connectivity across several services, use the whole-VPS network guide. If only SSH fails, use the SSH refusal and timeout guide. Those are different incidents from one application port.
Check whether the right process is listening
From an authorised console or SSH session on the VPS, an operator can run ss -lnt for listening TCP sockets, or ss -lnu for UDP sockets. Add -p only if you are authorised to see process names; that detail may require elevated privileges. Look for the expected port, address and address family. No listener means inspect the application’s service state and logs before changing firewall rules. A listener at 127.0.0.1:8080 is local to the guest; 0.0.0.0:8080 binds all IPv4 interfaces, subject to other controls. IPv6 bindings and dual-stack behaviour need their own check.
For an HTTP application, test the correct local protocol and port, for example curl -v --connect-timeout 5 http://127.0.0.1:8080/ if that is truly its configured local endpoint. A response locally but not remotely narrows the fault to the binding or path beyond the process. A failed local request points back to the application or its listener. Do not switch a private service to all interfaces just to make the test pass.
If it is containerised, inspect the host publication
A port visible inside a container is not necessarily published on the VPS host. If the customer operates Docker, inspect the running container’s published-port mapping with docker ps or docker port app-container (replace the illustrative container name), using an authorised account. Compare host port, container port and host bind address. Docker documents that an unspecified host address can publish on all interfaces; an explicit 127.0.0.1 host binding normally limits that host mapping to loopback, but Docker Engine releases before 28.0.0 can still expose localhost-published ports to hosts on the same L2 segment, and configured direct routing can provide another path to the container IP. Verify effective reachability rather than assuming isolation. Publishing a database or administrator UI broadly can expose it. Docker can also manage firewall rules in ways that bypass assumptions based solely on UFW status, so the container mapping and effective network path both matter.
A reverse proxy that terminates public HTTPS may intentionally connect to an application bound only to loopback. In that design, check the proxy’s public listener and upstream mapping, rather than publishing the application port directly.
Check each actual firewall layer without disabling it
Inspect the guest firewall that is installed and active. On Ubuntu with UFW, sudo ufw status verbose or sudo ufw status numbered shows the current rules; UFW may be disabled. On a firewalld system, inspect the active zone, its interfaces and allowed service or port. Check the correct transport and whether the rule is restricted to the intended source addresses. A rule for TCP does not open UDP, and an IPv4 rule does not automatically prove the IPv6 path.
Some VPS products or customer networks add another firewall or filtering layer; do not invent a Novasean panel control. If the accepted Order exposes one, compare its effective rule with the guest configuration. Keep an existing console route and a record of the previous rules before an authorised change. Never disable the whole firewall, widen to all sources or open an administrative port as a diagnostic shortcut. Ask the operator responsible for a layer you cannot inspect to check the exact destination, protocol and timestamps.
Test from outside and keep a rollback path
Test from a second network that is allowed by the intended access policy, using the application protocol and the exact hostname or IP and port. For a public HTTPS application on the documented example port, curl -v --connect-timeout 5 https://app.example.org:8443/ checks a normal client connection; replace the example hostname and port with the real endpoint. Do not bypass certificate validation to force a green result. A local success plus external timeout suggests filtering, routing, address-family or source-allowlist trouble; a quick refusal can also mean no listener or a deliberate reject. These symptoms alone do not identify a single culprit.
After an approved change, recheck the local listener, external access from an allowed source, access denial from a disallowed source where feasible, the application’s authentication and a restart or reload if the rule must persist. If exposure is broader than intended, revert only the new binding, publication or firewall rule and retest. Give support redacted command output, the exact destination and protocol, test source, time and observed error; do not send credentials or private application data.
Frequently asked questions
Why does an online port checker say closed when the application works locally? It may be testing the wrong address or transport, while the application listens only on loopback, a container has no host publication, or a firewall filters the path. Confirm the exact endpoint with a protocol-appropriate client.
Should I open port 8080 or 8443 to everyone? Only if the application is intended and hardened for public access. Many applications belong behind a reverse proxy, VPN or source-restricted rule. An open port is an access decision, not a repair by itself.
Does a UFW allow rule prove a Docker container is protected? No. Docker’s port-publication rules can change the effective packet path. Inspect Docker’s host binding and effective firewall behaviour together.
Can Novasean change every firewall layer for me? Only the controls included in the accepted service and within the agreed responsibility boundary. The customer or another provider may own the application, guest firewall, DNS or upstream network policy.
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.