All developers unconsciously accept and use the concept that `localhost` is equivalent to `127.0.0.1`, much like the mathematical notion that 1+1=2. However, just as mathematicians strive to prove why 1+1 equals 2, I unexpectedly found myself curious about this today. Consequently, I delved into the underlying principle and gained a new understanding of Linux's communication mechanism. This experience highlighted the logical rigor of developers, and I found myself amazed while uncovering the principle. Below is a summary of what I learned. ### 1. How does localhost connect to 127.0.0.1? {#sec-ca9e4e4da433} **Question**: Why does calling `localhost` connect to `127.0.0.1`? **Answer**: When a network request is made, the Linux system resolves the domain name to an IP address. During this process, it first checks the **/etc/hosts file**. By default, the /etc/hosts file includes the following configuration: ``` 127.0.0.1 localhost ``` `127.0.0.1` refers to the loopback interface, which means **it refers to itself**. Therefore, when you call `http://localhost` from your browser or terminal, Linux directs this request directly to `127.0.0.1` via the `/etc/hosts` file, bypassing DNS. Consequently, `localhost` functions internally in Linux as an **alias for itself**. ### 2. What is the /etc/hosts file and what role does it play? {#sec-ad56f0197aca} **Question**: How exactly does the /etc/hosts file work? **Answer**: The `/etc/hosts` file is one of the most fundamental mechanisms in Linux's **hostname resolution process**. When a network request occurs, Linux resolves the domain name to an IP address in the following order: 1. **Check the `/etc/hosts` file**: The **`getaddrinfo()`** function, provided by Linux's glibc library, is the starting point for all network requests. This function first checks the `/etc/hosts` file when resolving a domain's IP address. If the domain is defined in `/etc/hosts`, Linux uses this information to return the IP address directly, bypassing the DNS server. 2. **Query DNS server**: If the domain is not defined in the `/etc/hosts` file, it looks up the IP address via the configured DNS server. The `/etc/hosts` file applies to all network requests and operates consistently across various network request libraries such as browsers, `curl`, `ping`, and Python's `requests` module. ### 3. What can be achieved by utilizing /etc/hosts? {#sec-ad419e16cb9e} **Question**: What effect would adding a domain name to the /etc/hosts file have? **Answer**: By adding a desired domain name and IP address to the `/etc/hosts` file, requests for that domain will connect directly to the specified IP, bypassing DNS. For example: ``` 127.0.0.1 localhost 127.0.0.1 app1.local 127.0.0.1 app2.local ``` With this setup: * Requests to `app1.local` and `app2.local` will be **routed by Linux to `127.0.0.1`**. * This is useful for **virtual domain testing** or **internal communication between applications** in a development environment. * The requested domains have the same effect as **`localhost`** but can be handled independently. ### 4. How do Nginx and Gunicorn collaborate with /etc/hosts? {#sec-80edc0f3ebfd} **Question**: Can servers like Nginx and Gunicorn interact with the /etc/hosts file? **Answer**: Since web servers like Nginx operate above the Linux networking layer, they respect the domain mappings defined in `/etc/hosts`. For example: * If `127.0.0.1 app1.local` is set in `/etc/hosts`, Nginx routes requests for this domain to the application mapped to `127.0.0.1`. * You can set up virtual hosts in Nginx to differentiate requests by domain. Example: ```nginx server { server_name app1.local; location / { proxy_pass http://127.0.0.1:8000; # app1 service } } server { server_name app2.local; location / { proxy_pass http://127.0.0.1:8001; # app2 service } } ``` This configuration allows running two applications independently on the same server. ### 5. How is /etc/hosts useful in development environments? {#sec-aefc393ceb59} **Question**: In what situations is the /etc/hosts file actually useful? **Answer**: The `/etc/hosts` file is particularly useful in development and testing environments for the following situations: * **Local domain testing**: You can test specific domains in a local environment. For example, mapping `https://test.local` to a local application. * **DNS bypass**: Temporarily connect to a different IP without needing actual DNS server configurations. For example, routing `example.com` to another server IP. * **Internal communication between applications**: Using `/etc/hosts` for communication between multiple applications running on the same server reduces DNS requests and optimizes communication speed. ### 6. The value of /etc/hosts in dynamic IP and DNS cache issues {#sec-f333651f97a7} **Personal experience**: Developers using dynamic IPs typically resolve IP change issues through **DDNS** (Dynamic DNS). However, a common issue arises: Linux hosts maintain a **DNS cache**, which can cause them to continue using a previous IP until its **TTL (Time to Live)** expires. This can lead to issues where applications send TCP requests to outdated IPs unless the cache is manually cleared with the `sudo resolvectl flush-caches` command. To solve this problem, using `/etc/hosts` allows routing a specific domain to a fixed IP, bypassing DNS altogether. Through this, I discovered a way to **fundamentally prevent communication issues caused by IP changes**. It's quite impressive that such a simple configuration can be key to resolving these issues. ### In Conclusion {#sec-187573c6f32f} Through all this, I realized that `localhost` and the `/etc/hosts` file, which I had unconsciously used, are closely connected to the fundamental networking mechanism of Linux. The logical rigor with which Linux developers designed such fundamental structures fills me with awe. It's surprising how a single, simple file can play such an important role in both development and production environments. This experience reaffirmed how beneficial it is to understand the essence of technology. 😊 ![Illustration of the /etc/hosts file usage](/media/whitedec/blog_img/computer_screen_hosts_file.webp)