Record the expected service, port and protocol. Confirm whether it runs directly on the host, in a container or behind a proxy. Use authorized privileges to view process details and avoid publishing command lines that contain secrets.

1. Inspect TCP listeners with sudo ss -lntp and UDP sockets with sudo ss -lnup. Narrow the output to the intended port using ss filtering or careful inspection.
2. Read the local bind address. A loopback-only listener is different from one bound to a private address, all IPv4 interfaces or an IPv6 address.
3. Map the process ID to its service or container and inspect the supported configuration. Check whether a proxy intentionally owns the public port while the application listens privately elsewhere.
4. Test the service locally using its actual protocol, then from an authorized external client. A TCP handshake alone does not prove a correct HTTP, database or TLS response.
5. If the wrong process owns the port, resolve the configuration conflict through the service manager. Change or stop only the identified owner after assessing impact.

Run this on the Linux server you administer, using elevated access when needed to see process identities. Substitute the actual port if you are investigating SSH, a database or an application listener. The command only lists listening TCP sockets.

sudo ss -ltnp 'sport = :443'

Read the result: Match the process name and PID to the intended web service. A listener on 127.0.0.1 accepts local connections only; a wildcard address has a broader bind scope. Check IPv4 and IPv6 explicitly when the output shows more than one listener, because address-family settings can affect reachability.

No output means no matching TCP listener was visible in this network namespace at that moment. It does not identify which configuration should be changed. Check the owning service state, container mapping and network firewall before starting another server on the same port.

The service may bind only to loopback, or the external path may be blocked. Confirm the intended exposure before changing the bind address, especially for databases and administrative interfaces.

Confirm the intended process listens on the expected address/protocol and the service responds through the required network path. Review firewall and provider rules only after the listener and application health are understood.

For Address already in use, identify the existing socket instead of repeatedly starting another copy. If no listener exists, inspect service startup errors. If local access works but remote access fails, investigate binding, routing and filtering. Do not kill an unfamiliar process solely because it occupies a desired port.

• Investigating a failed systemd service
• Restricting Ubuntu firewall access without locking out SSH
• Managing firewalld zones and permitted services
• Separating DNS failure from network failure on Linux

• Debian manual: Ss.8.en
• Debian manual: Systemctl.1.en