Networking Fundamentals for DevOps Beginners

Modern applications communicate across networks. A frontend connects to an API, an API connects to a database, containers communicate with one another and users access applications through domains and web servers.

When any part of this communication fails, a DevOps engineer must determine whether the problem involves DNS, an IP address, a port, a firewall, a proxy, a route or the application itself.

This guide introduces the networking fundamentals you need for Linux servers, cloud platforms, Docker, Kubernetes and CI/CD.

If you are following our DevOps learning series, begin with the complete DevOps roadmap for beginners. You can also study Linux fundamentals for DevOps and Git and GitHub for DevOps beginners.

What Is a Computer Network?

A computer network is a group of connected devices that exchange information.

These devices can include:

Computers
Smartphones
Servers
Routers
Switches
Firewalls
Containers
Virtual machines
Cloud resources

Information is divided into small units called packets and transmitted between devices using agreed communication rules called protocols.

When you open a website, your device must find the server, establish a connection, send a request and receive a response. Several networking components participate in this process.

Why DevOps Engineers Need Networking

DevOps engineers regularly work with systems that communicate over private and public networks.

Networking knowledge helps with:

Connecting to remote servers through SSH.
Configuring web servers and reverse proxies.
Exposing applications on the correct ports.
Connecting applications to databases.
Configuring cloud networks and security groups.
Troubleshooting DNS problems.
Running applications inside containers.
Configuring Kubernetes services and ingress.
Setting up load balancers.
Securing communication using HTTPS.
Diagnosing failed deployments and connection errors.

You do not need to become a network engineer before learning DevOps. However, you should understand how application traffic travels and how to identify where communication is failing.

Understanding the OSI Model

The OSI model divides network communication into seven conceptual layers:

Physical
Data Link
Network
Transport
Session
Presentation
Application

DevOps engineers frequently work with the following layers:

Network layer: IP addresses and routing.
Transport layer: TCP, UDP and ports.
Application layer: HTTP, HTTPS, DNS and SSH.

The OSI model is useful during troubleshooting because it encourages you to examine the problem layer by layer.

For example, if a website is unavailable, you can check:

Is the server running?
Does it have the expected IP address?
Does DNS resolve to that address?
Is the required port open?
Is the web server listening?
Is the application responding correctly?

TCP/IP Model

Real internet communication is commonly described using the TCP/IP model.

Its main layers are:

Network access
Internet
Transport
Application

Important protocols include:

Protocol	Purpose
IP	Addresses and routes packets
TCP	Provides reliable, ordered communication
UDP	Provides fast communication without delivery guarantees
DNS	Converts domain names into IP addresses
HTTP	Transfers web requests and responses
HTTPS	Protects HTTP traffic using TLS
SSH	Provides secure remote access
DHCP	Assigns network configuration automatically

Understanding what each protocol does makes troubleshooting much easier.

What Is an IP Address?

An IP address identifies a device or network interface.

An IPv4 address looks like this:

192.168.1.20

IPv4 addresses contain four numbers separated by dots. Each number can range from 0 to 255.

An IPv6 address looks like this:

2001:db8:85a3::8a2e:370:7334

IPv6 provides a much larger address space and is increasingly important across modern networks and cloud environments.

On Linux, inspect network interfaces and addresses using:

ip addr

A shorter form is:

ip a

Public and Private IP Addresses

A public IP address can identify a resource on the public internet.

A private IP address is used inside a private network and is not directly routable across the public internet.

Common private IPv4 ranges are:

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

A cloud server may have both:

A private IP for communication with internal resources.
A public IP for access from the internet.

Applications and databases should not automatically be exposed publicly. For example, an application server can access a database through a private network while only the web server or load balancer accepts public traffic.

Understanding Localhost

The hostname localhost normally refers to the current machine.

Its common IPv4 loopback address is:

127.0.0.1

Its IPv6 loopback address is:

::1

If an application listens only on 127.0.0.1, it can normally be reached only from the same machine.

For example, a Next.js application might run locally at:

http://127.0.0.1:3000

Nginx can accept public requests on port 80 or 443 and forward them to that local application.

This arrangement allows the application server to remain unexposed while Nginx handles public traffic.

IP Address Versus Domain Name

An IP address identifies a destination on a network. A domain name provides a human-readable name for that destination.

For example:

example.com

DNS translates the domain into an IP address before the client connects to the server.

A domain is easier for people to remember, while DNS allows the underlying server address to be managed separately.

What Is DNS?

The Domain Name System translates domain names into IP addresses.

When you open a website, the basic process is:

The browser requests the IP address for the domain.
A DNS resolver searches for the answer.
The resolver returns the appropriate DNS record.
The browser connects to the returned address.
The browser sends an HTTP or HTTPS request.

Common DNS record types include:

Record	Purpose
A	Maps a name to an IPv4 address
AAAA	Maps a name to an IPv6 address
CNAME	Maps one hostname to another hostname
MX	Identifies mail servers
TXT	Stores text used for verification and email security
NS	Identifies authoritative name servers

Check a domain using:

dig example.com

You can also use:

nslookup example.com

To request only the IPv4 addresses with dig, use:

dig +short example.com A

DNS changes may not appear everywhere immediately because resolvers and browsers can cache earlier answers.

What Is a Port?

An IP address identifies a host, while a port identifies a particular service or application on that host.

A server can run multiple services using different ports.

Common ports include:

Port	Common service
22	SSH
25	SMTP
53	DNS
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
3000	Common development application port
8080	Common alternative HTTP port

A port number alone does not guarantee that a particular service is running. Applications can be configured to use different ports.

Display listening ports on Linux:

sudo ss -tulpn

Check a particular port:

sudo ss -tulpn | grep ':3000'

If the application is running but no expected port is listening, inspect the application configuration and logs.

TCP Versus UDP

TCP and UDP are transport-layer protocols.

TCP

TCP provides reliable and ordered delivery. It establishes a connection before exchanging data and can retransmit missing information.

TCP is commonly used by:

HTTP and HTTPS
SSH
Database connections
Email protocols
Git operations over SSH or HTTPS

UDP

UDP sends data without establishing the same type of reliable connection. It has less overhead but does not guarantee delivery or order.

UDP is commonly used for:

DNS queries
Streaming
Online gaming
Voice communication
Monitoring and discovery protocols

TCP is appropriate when complete and correctly ordered data is important. UDP can be useful when speed and low overhead are more important than retransmitting every lost packet.

What Are HTTP and HTTPS?

HTTP is the primary application protocol used for communication between web clients and servers.

A client sends a request containing:

A method
A path
Headers
An optional body

The server returns:

A status code
Headers
An optional response body

Common HTTP methods include:

GET — Retrieve a resource.
POST — Create or submit data.
PUT — Replace a resource.
PATCH — Partially update a resource.
DELETE — Remove a resource.

Common status codes include:

Status	Meaning
200	Request succeeded
201	Resource created
301	Permanent redirect
302	Temporary redirect
400	Invalid client request
401	Authentication required
403	Access forbidden
404	Resource not found
500	Internal server error
502	Bad response from an upstream server
503	Service unavailable
504	Upstream server timed out

HTTPS is HTTP protected using TLS. It encrypts the communication and helps the client verify the identity of the server.

Production websites should use HTTPS with a valid certificate.

Inspect website response headers using:

curl -I https://example.com

Display connection details with:

curl -v https://example.com

What Is a Firewall?

A firewall controls which network traffic is allowed or rejected.

A firewall rule may consider:

Source address
Destination address
Protocol
Port
Direction of traffic

On Ubuntu, UFW provides a convenient interface for firewall management.

Check its status:

sudo ufw status

Allow SSH:

sudo ufw allow OpenSSH

Allow HTTP and HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Avoid enabling a restrictive firewall on a remote server until you have confirmed that SSH access will remain available.

Cloud platforms also provide network controls such as:

AWS security groups
AWS network access control lists
Azure network security groups
Google Cloud firewall rules

Both the operating-system firewall and cloud network rules may affect a connection.

Routing and the Default Gateway

Routing determines where packets should be sent.

A routing table contains rules describing which network interface or gateway should be used for different destinations.

Display the Linux routing table:

ip route

A typical default route may look like:

default via 192.168.1.1 dev eth0

The default gateway receives traffic when no more specific route matches the destination.

Routing becomes especially important in cloud networks containing multiple subnets, VPN connections and private services.

What Is NAT?

Network Address Translation changes address information while traffic moves between networks.

NAT commonly allows several devices using private IP addresses to access the internet through one public IP address.

Cloud environments may use a NAT gateway to give servers in a private subnet outbound internet access without assigning public IP addresses directly to those servers.

NAT should not be confused with a firewall. NAT modifies address information, while a firewall decides whether traffic should be allowed.

Understanding Subnets

A subnet divides an IP network into smaller networks.

An address written as:

192.168.1.0/24

uses CIDR notation. The /24 indicates that the first 24 bits identify the network.

A /24 IPv4 subnet contains 256 total addresses, although some addresses are reserved or unavailable depending on the environment.

You do not need to master complex subnet calculations immediately. Begin by understanding:

The network address identifies the subnet.
A subnet mask separates network and host portions.
Smaller CIDR numbers represent larger networks.
Cloud virtual networks are divided into subnets.
Public and private subnets serve different exposure requirements.
Subnet ranges must not overlap when networks need to communicate directly.

Subnet planning is important when designing AWS VPCs, Kubernetes clusters and VPN connections.

What Is a MAC Address?

A MAC address identifies a network interface at the data-link layer.

It normally appears in a format such as:

00:1A:2B:3C:4D:5E

IP addresses support communication across networks, while MAC addresses are primarily used for communication within a local network segment.

ARP helps IPv4 devices determine which MAC address corresponds to a local IP address.

View the neighbour table on Linux:

ip neigh

What Is DHCP?

The Dynamic Host Configuration Protocol automatically provides network settings to devices.

These settings can include:

IP address
Subnet mask
Default gateway
DNS servers
Lease duration

Without DHCP, administrators would need to configure addresses manually on every device.

Servers may use static or reserved addresses so their network location remains predictable.

Reverse Proxies

A reverse proxy accepts client requests and forwards them to an application server.

Nginx is commonly used as a reverse proxy.

A typical request flow is:

Browser → Nginx → Application

Nginx might listen publicly on ports 80 and 443 while forwarding requests to:

http://127.0.0.1:3000

A simplified Nginx configuration is:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

A reverse proxy can provide:

TLS termination
Domain-based routing
Load distribution
Request logging
Compression
Caching
Security controls

A 502 Bad Gateway response often means the proxy could not communicate successfully with its upstream application.

Load Balancers

A load balancer distributes incoming traffic across multiple application instances.

A basic flow is:

Users → Load balancer → Application servers

Load balancers can perform health checks and stop sending requests to unhealthy instances.

They improve availability and scalability, but applications may need to be designed for multiple instances. Sessions, uploaded files and cached data should not depend entirely on one application server.

Managed load balancers are available from major cloud providers.

Cloud Networking Fundamentals

Cloud platforms provide virtual networking components similar to physical networking infrastructure.

In AWS, common components include:

Virtual Private Cloud
Public and private subnets
Route tables
Internet gateways
NAT gateways
Security groups
Network access control lists
Elastic load balancers
Private and public IP addresses

A typical cloud architecture may use:

A public load balancer receiving HTTPS traffic.
Application servers in private subnets.
A database in private subnets.
Security rules allowing only required communication.
A NAT gateway for controlled outbound access.
DNS pointing the domain to the load balancer.

Follow the principle of least privilege. Do not expose a database to the entire internet when only application servers need to access it.

Networking in Docker

Docker creates virtual networks that allow containers to communicate.

List Docker networks:

docker network ls

Inspect a network:

docker network inspect bridge

In Docker Compose, services on the same network can normally communicate using their service names.

For example, an application may connect to PostgreSQL using:

postgres:5432

instead of:

localhost:5432

Inside a container, localhost refers to that container itself. It does not automatically refer to the host computer or another container.

This distinction causes many beginner networking problems.

Networking in Kubernetes

Kubernetes networking introduces several important resources:

Pod: Runs one or more containers and receives an IP address.
Service: Provides a stable way to access a group of pods.
ClusterIP: Exposes a service inside the cluster.
NodePort: Exposes a service through a port on cluster nodes.
LoadBalancer: Requests an external load balancer when supported.
Ingress: Routes external HTTP and HTTPS traffic to services.
NetworkPolicy: Controls allowed traffic between workloads.

Pods can be replaced and receive new IP addresses. Applications should generally connect through Kubernetes Services instead of depending directly on individual pod IP addresses.

Essential Networking Commands

Inspect network interfaces

ip addr

Inspect routes

ip route

Test basic reachability

ping -c 4 example.com

Some servers block ICMP traffic, so an unsuccessful ping does not always prove that a website is unavailable.

Check DNS

dig example.com

Test an HTTP endpoint

curl -I https://example.com

Display listening ports

sudo ss -tulpn

Trace the route to a destination

traceroute example.com

On some systems you may need to install traceroute first.

Test whether a TCP port is reachable

nc -vz example.com 443

Inspect a TLS certificate

openssl s_client -connect example.com:443 -servername example.com

View the public IP address

curl https://api.ipify.org

Use external IP-checking services only when appropriate for the environment and its security policies.

A Structured Troubleshooting Process

Suppose a website returns an error or cannot be opened.

Use this sequence:

1. Check the domain

dig +short example.com

Confirm it resolves to the expected destination.

2. Test network reachability

ping -c 4 server-ip

Remember that ping may be blocked even when the web service is working.

3. Test the required port

nc -vz server-ip 80
nc -vz server-ip 443

4. Test the web response

curl -I http://server-ip
curl -I https://example.com

5. Check listening services

On the server:

sudo ss -tulpn

6. Check service status

sudo systemctl status nginx
sudo systemctl status your-application

7. Test the application directly

If the application should listen locally on port 3000:

curl -I http://127.0.0.1:3000

If this succeeds but the public domain fails, investigate Nginx, DNS, TLS and firewall settings.

8. Inspect logs

sudo journalctl -u nginx --since today
sudo tail -f /var/log/nginx/error.log

Also inspect the application’s own logs.

9. Check firewall rules

sudo ufw status

For a cloud server, inspect its security group or equivalent network rules.

10. Check configuration

Confirm:

Correct IP address
Correct domain
Correct port
Correct upstream address
Correct protocol
Valid TLS certificate
Required environment variables
Correct proxy configuration

Change one thing at a time and retest. Randomly changing several settings can make the original problem harder to identify.

Common Networking Errors

Connection refused

This usually means the destination responded, but no application accepted the connection on the requested port.

Possible causes include:

The application is stopped.
The application listens on another port.
The application listens on the wrong interface.
A firewall rejects the connection.

Connection timed out

Possible causes include:

Firewall rules silently drop traffic.
The route is unavailable.
The destination is offline.
A cloud security rule blocks the connection.
The application or upstream service is unresponsive.

DNS name not resolved

Possible causes include:

The DNS record does not exist.
The record is incorrect.
The resolver is unavailable.
A recent DNS change remains cached.
The local network has a DNS problem.

404 Not Found

A 404 response means a web server was reached, but it could not find the requested resource.

This is different from a network connection failure.

502 Bad Gateway

A reverse proxy received an invalid response or could not successfully communicate with its upstream application.

Check:

The application process
The upstream IP and port
Application logs
Proxy configuration
Local firewall rules
Whether the application uses HTTP or HTTPS internally

504 Gateway Timeout

A proxy or load balancer waited too long for an upstream service.

Investigate slow application code, database queries, downstream APIs, resource exhaustion and timeout settings.

Networking Security Best Practices

Follow these practices when configuring networks:

Expose only required ports.
Use HTTPS for public applications.
Keep databases on private networks when possible.
Restrict SSH access to trusted sources.
Use SSH keys instead of password authentication.
Apply least-privilege firewall rules.
Separate public and private resources.
Rotate compromised keys and certificates.
Monitor unusual network activity.
Keep operating systems and network services updated.
Avoid placing secrets in URLs or public configuration files.
Review cloud security groups regularly.
Back up network and proxy configurations before major changes.

Do not disable a firewall permanently just to make an application work. Identify and allow only the required traffic.

Practical Networking Project

Create an Ubuntu virtual machine or cloud server and complete the following project:

Install Nginx.
Create a basic website.
Confirm Nginx listens on port 80.
Allow HTTP through the firewall.
Access the website using the server IP.
Connect a domain to the server.
Verify the DNS record using dig.
Configure Nginx with the domain.
Add HTTPS using a valid certificate.
Inspect the TLS certificate.
Run a Node.js application on port 3000.
Configure Nginx as its reverse proxy.
Confirm port 3000 is not unnecessarily exposed publicly.
Inspect access and error logs.
Stop the application and observe the resulting proxy error.
Restart it and verify recovery.

Document every command, configuration and test result. This project combines DNS, ports, firewalls, HTTP, HTTPS, Linux services and reverse proxies.

Common Mistakes to Avoid

Beginners should avoid:

Assuming that ping tests the complete application.
Exposing database ports publicly.
Opening every firewall port.
Confusing localhost with another machine or container.
Forgetting cloud security-group rules.
Changing DNS without verifying the destination.
Using an IP address where a hostname is required for TLS.
Ignoring proxy and application logs.
Treating every 404 as a networking problem.
Disabling security controls instead of diagnosing them.
Testing only from inside the server.
Forgetting that DNS results can be cached.

Always determine whether a failure occurs at the DNS, connection, TLS, proxy or application layer.

Frequently Asked Questions

Is networking required for DevOps?

Yes. DevOps engineers work with servers, containers, APIs, databases and cloud resources that communicate over networks. Basic networking knowledge is essential for deploying and troubleshooting these systems.

Do I need to learn subnetting?

You should understand IP ranges, CIDR notation, public and private subnets, routing and overlapping networks. Advanced subnet calculations can be learned gradually as you work with cloud infrastructure.

What networking commands should a beginner learn first?

Start with:

ip addr
ip route
ping
curl
dig
ss
nc
traceroute

Learn what each command verifies instead of memorizing commands without understanding their output.

What is the difference between a firewall and a security group?

A firewall is a general system for controlling traffic. A cloud security group is a cloud-provider network control attached to resources or network interfaces. A server may be affected by both operating-system firewall rules and cloud security rules.

What should I learn after networking?

After Linux, Git and networking fundamentals, continue with Docker. Docker will help you understand how applications and their dependencies can be packaged and run consistently across different environments.

Conclusion

Networking connects every major part of a modern application. DevOps engineers use networking knowledge to configure servers, expose applications, connect databases, troubleshoot deployments and secure cloud environments.

Begin with IP addresses, DNS, ports, TCP, UDP, HTTP, routing and firewalls. Then practise using Linux networking commands on a real server.

The most valuable skill is not memorizing definitions. It is learning how to follow a request from the user through DNS, a firewall, a web server and an application until you identify exactly where it fails.

Continue your learning with our DevOps, Linux and technology guides. The next article in this series will explain Docker fundamentals for DevOps beginners.