In DevOps, many âapplication problemsâ are really networking problems. A service may be healthy but unreachable, a DNS name may resolve incorrectly, or a firewall may block the expected port.
Linux includes strong networking tools for checking addresses, routes, listening ports, remote connectivity, and file transfers.
ip addrThe modern command for viewing network interfaces and addresses is ip.
ip addr
ip addr show eth0This tells you what IP addresses are assigned to each interface.
If a server has no expected address, that is your first clue something is wrong.
ip routeRouting decides where traffic goes.
ip routeExample output may show a default gateway such as:
default via 10.0.0.1 dev eth0Without a correct default route, the host may reach the local subnet but not the internet or remote networks.
pingping checks whether a host responds to ICMP echo requests.
ping 8.8.8.8
ping example.comIf ping 8.8.8.8 works but ping example.com fails, the issue may be DNS rather than raw network connectivity.
Note: Some hosts block ICMP, so a failed ping does not always mean the service is down.
curl and wgetcurl is a versatile tool for making HTTP requests and testing APIs.
curl https://example.com
curl -I https://example.com
curl -X GET https://api.example.com/health-I fetches headers only, which is great for quick checks.
wget is commonly used to download files.
wget https://example.com/archive.tar.gzUse curl for flexible request testing and wget when your main goal is downloading.
ss and netstatss is the modern tool for socket statistics.
ss -tuln
ss -tulpnUseful flags:
-t TCP sockets-u UDP sockets-l listening only-n numeric output, no DNS lookup-p process infonetstat may still appear in older guides:
netstat -tulnpOn newer systems, ss is usually preferred.
nmapnmap helps discover open ports and services.
nmap localhost
nmap -p 22,80,443 example.comBeginners should use it responsibly and only on systems they are authorized to scan.
Tip: Even a basic
nmapscan can quickly confirm whether a port is reachable from your current machine.
sshssh is the standard tool for secure remote shell access.
ssh devops@server.example.com
ssh -i ~/.ssh/id_rsa devops@server.example.comIt is the backbone of Linux server administration.
If SSH fails, common causes include DNS issues, firewall rules, wrong keys, or the service not listening on the expected port.
scp and rsyncUse scp for straightforward secure copies.
scp app.conf devops@server:/etc/myapp/
scp devops@server:/var/log/app.log ./Use rsync for more efficient sync behavior, especially on repeated transfers.
rsync -av ./site/ devops@server:/var/www/site/rsync copies only changed data, which makes it great for deployments and backups.
/etc/hosts and DNS ResolutionDNS translates names like api.example.com into IP addresses. Linux can also use /etc/hosts for local name overrides.
Example entry:
10.0.0.15 internal-api.localThis is useful for testing or temporary overrides, but it can also create confusion if it points to an outdated address.
A good troubleshooting habit is checking whether a name resolves the way you expect.
Suppose a service is âdown.â You could check:
ip addr
ip route
ping api.example.com
curl -I https://api.example.com/health
ss -tulpn | grep 443That sequence answers key questions:
Scenario: ping 8.8.8.8 works, but ping example.com fails.
Question: Based on the lesson, what is the most likely category of problem?
<MCQExercise exercise={{
id: 'linux-networking-q1',
title: 'Exercise 1: Diagnosing a name-resolution failure',
description: 'Decide what a working IP ping but failing hostname ping usually points to.',
options: [
{ id: 'a', text: 'Disk space is full under /var.' },
{ id: 'b', text: 'DNS resolution is likely the issue.' },
{ id: 'c', text: 'The shell lost execute permission.' },
{ id: 'd', text: 'The host has no network interface at all.' },
],
correctId: 'b',
explanation: 'The tutorial explicitly uses this comparison to separate DNS problems from underlying network reachability. If an IP address works but a hostname does not, name resolution is a strong suspect.',
wrongExplanations: {
a: 'Full disk space can cause many issues, but it does not explain why a raw IP ping works while a hostname ping fails.',
c: 'Shell execute permissions are unrelated to DNS lookups.',
d: 'If there were no working interface, the direct ping to 8.8.8.8 would not succeed either.',
},
}} />
Question: Which command from the lesson is best for seeing listening TCP and UDP sockets with process information?
<MCQExercise exercise={{
id: 'linux-networking-q2',
title: 'Exercise 2: Inspecting listening services',
description: 'Choose the modern socket inspection command with listening and process details.',
options: [
{ id: 'a', text: 'ip route' },
{ id: 'b', text: 'ss -tulpn' },
{ id: 'c', text: 'curl -I https://example.com' },
{ id: 'd', text: 'whoami' },
],
correctId: 'b',
explanation: 'The tutorial recommends ss as the modern tool for socket statistics and explains the combined flags: TCP, UDP, listening, numeric output, and process info. That makes ss -tulpn ideal when you need to confirm what is bound to a port.',
wrongExplanations: {
a: 'ip route shows routing information, not which process is listening on a socket.',
c: 'curl tests HTTP responses, but it does not enumerate local listening ports.',
d: 'whoami only prints the current user identity.',
},
}} />
Question: Why might rsync be a better fit than scp for sending a site directory to a server again and again?
<MCQExercise exercise={{
id: 'linux-networking-q3',
title: 'Exercise 3: Efficient repeated file syncs',
description: 'Identify the advantage rsync provides for repeated transfers.',
options: [
{ id: 'a', text: 'rsync can only copy files locally, so it avoids network overhead completely.' },
{ id: 'b', text: 'rsync replaces SSH and does not need remote access.' },
{ id: 'c', text: 'rsync copies only changed data, which is efficient for repeated sync operations.' },
{ id: 'd', text: 'rsync automatically edits DNS records after the transfer.' },
],
correctId: 'c',
explanation: 'The lesson describes rsync as especially useful for repeated transfers because it sends only changed data. That makes it faster and more efficient than blindly copying an entire directory every time.',
wrongExplanations: {
a: 'rsync absolutely can operate over the network. Its advantage is smart synchronization, not being local-only.',
b: 'rsync commonly uses SSH for secure remote transfers rather than replacing it.',
d: 'File synchronization and DNS management are separate tasks. rsync does not update DNS records.',
},
}} />
ip replaced ifconfig and route. ss replaced netstat. Learn the new ones.ss -tlnp is the workhorse: which ports are listening and which process owns each.ping failing does not mean "down". Plenty of hosts drop ICMP while serving traffic normally.curl -v distinguishes DNS, TCP and TLS failures by showing exactly which stage did not complete.127.0.0.1 is unreachable from anywhere else, no matter what the firewall says./etc/hosts wins over DNS, which makes it both a useful override and an easy thing to forget about.rsync over scp for anything repeated. It resumes, it is incremental, and scp is deprecated.sudo ss -tlnp, t for TCP, l for listening only, n for numeric ports rather than service names, p for the owning process. Add u for UDP. The sudo matters: without it you still see the ports but not which process owns them. Read the local address carefully, because 127.0.0.1:5432 means only that machine can connect while 0.0.0.0:5432 means anything that can route to the host can.
Because they test different layers. ping uses ICMP and confirms the host is reachable; a service needs a TCP port open, something listening on it, and no firewall in between. Work up the stack: ss -tlnp on the server to confirm something is listening and on which address, then curl -v telnet://host:port or nc -zv host port from the client to test the port, then check ufw status or the cloud security group. The most frequent cause is the service bound to 127.0.0.1 rather than 0.0.0.0.
ICMP is frequently blocked, by a firewall, a cloud security group, or as policy, and none of that affects normal traffic. AWS security groups, for instance, do not permit ICMP by default, so a perfectly healthy EC2 instance serving HTTPS will not answer a ping. Test the port you actually care about instead: nc -zv host 443 or curl -I https://host. A failed ping is weak evidence either way.
dig +short example.com asks DNS directly and shows the answer, and dig @8.8.8.8 example.com compares against a public resolver to distinguish a broken local resolver from a genuine DNS problem. resolvectl status shows which servers systemd-resolved is actually using. Check /etc/hosts too. It takes precedence over DNS entirely, so a stale entry there overrides whatever DNS says and is easy to forget. Inside containers, check /etc/resolv.conf, which the runtime writes.
scp copies files over SSH and copies everything, every time. rsync compares source and destination first and transfers only the differences, resumes interrupted transfers with --partial, can delete files that no longer exist at the source with --delete, and reports progress. For a one-off small file either is fine; for anything repeated or large, rsync -avz is substantially faster. OpenSSH has also deprecated the scp protocol on security grounds, which is another reason to standardise on rsync or sftp.
Find what went wrong in Linux logs: /var/log versus the systemd journal, tail -F over -f, grep filtering, logrotate, journald size caps and error triage.
Triage Linux performance in order: CPU, memory and I/O. Learn what load average counts, why free memory looks low and how to read iowait with vmstat.
Learn what Linux is: kernel versus distribution versus shell, which distro to learn for DevOps, and why servers and containers overwhelmingly run Linux.