Understanding Domains, DNS, Servers, and Reverse Proxies

A structured guide to demystify domain names, DNS records, servers, and how everything works together with Nginx/Apache.

---

1. Domain Basics

• A domain name (e.g., myapp.com) is just a human-readable label.
• When you buy a domain, you’re only buying the name, not the hosting or server.
• To make it work, you must link the domain to a server IP (where your app is hosted).

---

2. DNS Records (Mapping Domain to Server)

DNS records define how your domain/subdomain points to IPs or other domains.

• A Record → Maps domain → IPv4 address
  
  Example: myapp.com A 123.45.67.89

• AAAA Record → Maps domain → IPv6 address

• CNAME Record → Maps domain → another domain
  
  Example: www.myapp.com CNAME myapp.com

• Subdomains:

• api.myapp.com A 123.45.67.89

• blog.myapp.com A 123.45.67.89

→ All point to the same server IP.

---

3. How Subdomains Work on a Single Server

• Your server usually has one public IP.
• All subdomains (api.myapp.com, blog.myapp.com) resolve to this same IP.
• When the request reaches the server, the web server (Nginx/Apache) checks the Host header to know which site/subdomain was requested.
• Based on that, it serves different apps (via Virtual Hosts or server blocks).

---

4. Role of Web Servers (Nginx / Apache)

Nginx or Apache does:

1. Listens on ports 80 (HTTP) and 443 (HTTPS).
2. Reads the Host header (api.myapp.com, blog.myapp.com).
3. Matches it with configuration (sites-available in Nginx).
4. Serves the correct project folder or proxies the request to backend apps.

Project Files

• Static apps (React, Angular, etc.): Deploy the build folder (HTML, JS, CSS).
• Dynamic apps (Node.js, Django, etc.): Run app on internal port (e.g., 5000), then reverse proxy with Nginx.

---

5. Reverse Proxy Explained

Why do we need it?

• Backend apps don’t (and shouldn’t) run directly on port 80/443.
• They usually run on local ports like 5000, 8000, etc.
• Outsiders don’t see or access those ports.

👉 Reverse Proxy = Gateway

• User → https://api.myapp.com (port 80/443).
• Nginx forwards it → http://localhost:5000.
• App responds → Nginx sends back to user.

---

6. Why Not Direct Backend Usage?

• Security: Don’t expose raw app ports.
• Clean URLs: Users see only myapp.com, no :5000.
• SSL: Nginx handles HTTPS certificates.
• Load Balancing: Can distribute across multiple backend servers.

---

7. Example Setup with Nginx

Backend

• Run a Node.js/Django app on: http://localhost:5000

Nginx Config

server {
  listen 80;
  server_name api.myapp.com;

  location / {
      proxy_pass http://localhost:5000;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
  }
}

Flow

• Browser → https://api.myapp.com/login
• Request hits Nginx (port 80/443)
• Nginx forwards to backend (localhost:5000)
• Backend responds → Nginx passes it back → Browser shows result

8. Summary Workflow

1. Buy domain (get the name).
2. Set DNS records → Domain → Server IP.
3. Server receives requests → Nginx/Apache listens.
4. Nginx decides → Based on domain/Host header.
5. Serve files (static build) OR proxy to backend (dynamic apps).
6. User only sees clean domain (no internal ports).