How It Works
A hosts file contains lines that pair an IP address with one or more hostnames. When an application asks the operating system to resolve a hostname, the OS consults the Name Service Switch configuration (on Unix-like systems) or its equivalent on Windows, which typically places the hosts file before DNS in the lookup order. If a matching entry is found, the local answer is returned immediately and no DNS query is sent.
File Format and Parsing Rules
The hosts file format is simple and consistent across platforms. Each non-blank line that does not begin with a # character is treated as a record. The record starts with an IP address (IPv4 or IPv6), followed by one or more hostnames separated by whitespace. Comments begin with # and may appear on their own line or at the end of a record line. The parser is not case-sensitive for hostnames. Entries are matched top to bottom; the first match wins, so order matters when the same hostname appears more than once. There is no TTL field, no wildcard support, and no way to specify a port — the file maps hostnames to addresses only.
| Entry | Effect |
|---|---|
127.0.0.1 localhost | Maps localhost to the loopback address |
::1 localhost | IPv6 loopback for the same name |
203.0.113.10 staging.example.com | Sends that hostname to a specific staging server |
0.0.0.0 ads.tracker.example | Blocks the hostname by routing to an unroutable address |
192.168.1.50 nas nas.home | Assigns two names to one local device |
Order of Resolution: Hosts vs DNS
On Linux and macOS, the lookup order is controlled by /etc/nsswitch.conf. The relevant line typically reads hosts: files dns, meaning the OS checks the hosts file first, then queries DNS. On macOS, mDNS is also in the chain: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4. On Windows, the hosts file is consulted before DNS by default, though this is configurable through the registry and the advanced TCP/IP settings. Applications that bypass the system resolver — such as some browsers using their own DNS-over-HTTPS stack — may not consult the hosts file at all, which can surprise developers relying on hosts entries for local testing.
Per-OS File Locations
| Operating System | Hosts File Path | Required Permission |
|---|---|---|
| Windows 10/11 | C:\Windows\System32\drivers\etc\hosts | Administrator |
| macOS | /etc/hosts | sudo / root |
| Linux (most distros) | /etc/hosts | sudo / root |
| Android (rooted) | /system/etc/hosts | Root required |
| iOS (jailbroken) | /etc/hosts | Root required |
Flushing DNS Cache After Edits
Editing the hosts file takes effect immediately for new lookups on most systems, but existing cached answers may persist in the OS DNS cache. After making changes, flushing the DNS resolver cache ensures that stale answers do not interfere. On Windows, the command is ipconfig /flushdns. On macOS the command varies by OS version; on recent versions it is sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux with systemd-resolved, use sudo resolvectl flush-caches. Some browsers maintain their own internal DNS cache independently of the OS cache; Chrome's can be flushed at chrome://net-internals/#dns.
Use Cases
- Previewing a site on a new server before the public DNS record is updated.
- Testing a hostname against a staging environment without changing DNS.
- Creating short local names for lab services on a developer workstation.
- Blocking known ad networks or trackers on a single device using
0.0.0.0mappings. - Diagnosing whether a connectivity problem is in DNS or at the destination itself.
- Overriding a CDN edge address to test a specific origin server directly.
Limitations
The hosts file has several hard constraints that make it unsuitable as a general DNS replacement. It does not support wildcard entries — you cannot write *.example.com to cover all subdomains. There is no TTL, so entries remain until manually removed or the file is edited again. IPv6 and IPv4 must be listed as separate lines for the same hostname. The file is per-device and not synchronized across a network, so changes must be replicated to every machine that needs them. Large blocklists with tens of thousands of entries can slow down name resolution noticeably on some systems because the file is parsed linearly.
Security Risks: Malware and Forgotten Entries
Because the hosts file takes priority over DNS, it is a high-value target for malware. Trojans and adware commonly modify the hosts file to redirect antivirus update servers, banking sites, and search engines to attacker-controlled IP addresses. This prevents the victim from reaching security tools and enables phishing without any DNS infrastructure. On Windows, the hosts file has historically been writable by low-privilege processes unless hardened, which made it easy for malware to modify silently. A sudden inability to reach security software or specific websites on one machine — while the rest of the network works fine — is a signal to inspect the hosts file. Security tools typically monitor it for unexpected changes. Administrators should also audit for stale development entries left by team members, as a forgotten redirect to a decommissioned staging server can cause intermittent failures that are difficult to diagnose.
Frequently Asked Questions
What does a hosts file do?
A hosts file maps hostnames to IP addresses locally on one device, often before the device asks DNS.
Can a hosts file block websites?
Yes. Mapping a hostname to 0.0.0.0 or 127.0.0.1 can prevent that device from reaching the real site, though it is easy to bypass or forget.
Can malware change the hosts file?
Yes. Malware may alter hosts entries to redirect security sites, banks, search engines, or update servers. Unexpected hosts entries should be investigated.