Day 19: Server - NGINX ~ Your Swiss Army Knife for Web Hosting!

Experienced Senior DevOps Engineer with a passion for optimizing software development and delivery processes. Excels in designing and implementing CI/CD pipelines, automating infrastructure, and optimizing cloud architectures. Proficient in a wide range of DevOps tools such as Docker, Kubernetes, Jenkins, Ansible, Git, and AWS services. Strong collaborator, adept at fostering cross-functional teamwork and continuous improvement. Thrives in dynamic environments, utilizing problem-solving skills to overcome complex challenges. Dedicated to delivering high-quality software products on time and within budget.
NGINX is a high-performance, open-source web server, and reverse proxy server. It is designed to handle a large number of concurrent connections efficiently, making it a popular choice for serving static content, acting as a load balancer, and proxying requests to other application servers. NGINX is known for its lightweight and low resource consumption, making it an excellent choice for high-traffic websites and modern web applications.
Here are the different types of NGINX and their use cases:
NGINX as a Web Server:
Use Case: NGINX can serve static files, such as HTML, CSS, JavaScript, and images, directly to clients, handling static content delivery efficiently. It is an excellent choice for hosting static websites and assets.Example Configuration:
server { listen 80; server_name example.com; location / { root /var/www/example; index index.html; } }In this example, NGINX listens on port 80 for requests to
example.com. It serves static content from the directory/var/www/exampleand the default file for directory listing isindex.htmlNGINX as a Reverse Proxy:
Use Case: NGINX can act as a reverse proxy, forwarding client requests to backend application servers. This setup is often used to load balance requests across multiple application servers, improving application performance and ensuring high availability.Example Configuration:
upstream backend_servers { server 192.168.0.101:8080; server 192.168.0.102:8080; } server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_servers; } }In this example, NGINX acts as a reverse proxy for the backend application servers located at
192.168.0.101and192.168.0.102, which serve requests on port8080. NGINX forwards client requests to these backend servers based on theproxy_passdirective.NGINX as a Load Balancer:
Use Case: NGINX can distribute incoming client requests across multiple backend servers, balancing the load to prevent any single server from being overwhelmed. It ensures even distribution of traffic and helps scale applications horizontally.
Example Configuration:upstream backend_servers { server 192.168.0.101; server 192.168.0.102; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend_servers; } }In this example, NGINX acts as a load balancer for the backend servers at
192.168.0.101and192.168.0.102. NGINX distributes incoming requests between these servers using a simple round-robin algorithm.NGINX as an SSL/TLS Termination Proxy:
Use Case: NGINX can handle SSL/TLS encryption and decryption for incoming requests, relieving the backend application servers from this resource-intensive task. It is often used to offload SSL processing and improve the performance of application servers.
Example Configuration:server { listen 443 ssl; server_name secure.example.com; ssl_certificate /path/to/certificate.crt; ssl_certificate_key /path/to/private.key; location / { proxy_pass http://backend_server; } }In this example, NGINX listens on port 443 for secure requests to
secure.example.com. It terminates SSL/TLS encryption using the provided certificate and key before forwarding requests to the backend server.NGINX as an API Gateway:
Use Case: NGINX can act as an API gateway, routing and proxying API requests to backend services. It provides rate limiting, authentication, and request/response transformations to simplify API management and improve security.Example Configuration:
server { listen 80; server_name api.example.com; location /v1/ { limit_req zone=api_limit burst=10 nodelay; proxy_pass http://backend_server; } }In this example, NGINX listens on port 80 for requests to
api.example.com. It uses thelimit_reqdirective to set a request rate limit for the/v1/endpoint. Requests exceeding the rate limit will be delayed (nodelay) or rejected.NGINX for Microservices Architecture:
Use Case: In a microservices architecture, NGINX can be used as an API gateway and reverse proxy to handle incoming client requests and route them to the appropriate microservices. It helps decouple services and improves overall scalability and maintainability.
Example Configuration:upstream service_one { server 192.168.0.101:8080; } upstream service_two { server 192.168.0.102:8080; } server { listen 80; server_name api.example.com; location /service1/ { proxy_pass http://service_one; } location /service2/ { proxy_pass http://service_two; } }In this example, NGINX forwards requests for
/service1/to the backend service at192.168.0.101:8080, and requests for/service2/to the backend service at192.168.0.102:8080.NGINX as a Caching Proxy:
Use Case: NGINX can cache static content and responses from backend servers, reducing the load on the application servers and improving response times for clients.
Example Configuration:proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m; server { listen 80; server_name example.com; location / { proxy_pass http://backend_server; proxy_cache my_cache; proxy_cache_valid 200 304 1d; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; } }In this example, NGINX uses a cache named
my_cacheto store responses from the backend server. Responses with a200or304status code will be cached for 1 day.NGINX for Web Application Firewall (WAF):
Use Case: NGINX can be configured as a WAF to inspect incoming traffic, filter out malicious requests, and protect web applications from common attacks like SQL injection, cross-site scripting (XSS), and more.
Here's an example configuration for using NGINX as a Web Application Firewall (WAF) to protect a web application from common attacks like SQL injection and Cross-Site Scripting (XSS):
# nginx.conf http { # Define the WAF rules map $request_uri $block_request { default 0; ~*sql_injection 1; ~*xss_injection 1; } server { listen 80; server_name myapp.example.com; # Block requests based on WAF rules if ($block_request) { return 403; } location / { # Forward the request to the backend application server proxy_pass http://backend_server; } } }In this example:
We define two WAF rules using the NGINX
mapdirective. The first rulesql_injectionis designed to match requests with potential SQL injection attempts in the request URI ($request_uri). The second rulexss_injectionis designed to match requests with potential Cross-Site Scripting (XSS) attempts in the request URI.Inside the
serverblock, we check if the request URI matches any of the defined WAF rules using theif ($block_request)condition. If there is a match, the request is blocked with a403 Forbiddenresponse.If the request passes the WAF checks, it is considered safe, and we forward it to the backend application server using the
proxy_passdirective.
NGINX is a versatile and powerful tool that can be used in various scenarios to enhance the performance, security, and scalability of web applications and services. Its flexibility and extensive feature set have made it a popular choice for many high-traffic websites, web applications, and API services.
Thanks for reading! I hope you found this blog informative and insightful. For more technology-related content, don't forget to follow me on GitHub and LinkedIn




