JuniorLinux

How do you check what is listening on a port, and test whether you can reach a remote service?

What they are really testing: Practical host networking, the daily "is it the app, the port, or the network" triage. They want the modern tools and a sense of layering the checks.

A real interview question

How do you check what is listening on a port, and test whether you can reach a remote service?

What most people say

drag me

I would ping the server to see if it is up.

Ping only tests ICMP reachability, not the port or the service, and many hosts block ICMP entirely. It cannot tell you if the actual service is listening or reachable.

The follow-ups they ask next

  • curl hangs with no response. Refused vs timeout, what does each tell you?

    Connection refused = reached the host, nothing listening on that port (or app down). Timeout/hang = packets are being dropped, usually a firewall/security group or routing issue, not the app.

  • The service listens on 127.0.0.1 but you need remote access. What do you change?

    Bind it to 0.0.0.0 (or the specific interface) in the app/service config, then ensure the firewall/security group allows the port. Binding alone is not enough if the firewall blocks it.

What the interviewer is listening for

  • Uses ss/netstat to confirm listening
  • Checks the bind address (127.0.0.1 vs 0.0.0.0)
  • Distinguishes refused vs timeout
  • Layers DNS/port/app

What sinks the answer

  • Relies on ping alone
  • Doesn't check the bind address
  • Can't interpret refused vs timeout

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

Locally I use [ss -tlnp to see listeners + the bind address, 127.0.0.1 is localhost-only]. To test remote I use [curl or nc -vz host port]. Then I layer it: [refused = nothing listening, timeout = firewall, DNS fails = resolution]. Ping alone [only tests ICMP, often blocked].

Keep going with linux

All 336 cloud engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free