# ineo6/hosts: a GitHub hosts file that updates on a schedule

> ineo6/hosts publishes a hosts file for speeding up GitHub access and ships a local hosts-server binary that resolves addresses on your machine. The project is small, MIT licensed, and its last push was on 2022-04-23.

**ineo6/hosts** — GitHub hosts GitHub GitHub . GitHub Hosts GitHub GitHub Hosts host GitHub : : Github Pages: GitHub FastDev hosts GitHub Gitlab 1.

- Repository: https://github.com/ineo6/hosts
- Website: https://ineo6.github.io/hosts/
- Stars: 5,364 · Forks: 457
- Language: TypeScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ineo6-hosts

## The problem ineo6/hosts addresses, and who it is for

GitHub access from some networks is slow, and images on the site sometimes fail to load. The README describes the project's most visible effect in one line: GitHub images load normally and the page becomes stable. It does this by editing the hosts file, the local mapping from hostname to IP address, so that github.com and its asset domains resolve to addresses that were measured to work.

The audience is narrow and practical. It is for developers on macOS, Windows or Linux who want GitHub to open faster and who are willing to modify a system file or run a small local server. It is not a general DNS tool, not a VPN, and not a proxy. The README also points readers at a separate tool, FastDev, described as a new GitHub access acceleration tool that is waiting for trial and feedback, so the author treats this project as one part of a wider set of utilities.

## How the hosts list and the local server actually work

There are two delivery paths, and they behave differently.

The first is a remote hosts file. The repository keeps a hosts file and a next-hosts file at the top level. The README says the next-hosts variant is generated with a DNS-based approach and is updated on a timer; the copy shown in the README carries the line "Update at: 2023-03-08 20:22:25". You point a hosts manager at the raw URL and it pulls the current list. The addresses in that list are whatever the generator last produced, so their quality depends on the network the generator ran from, not on yours.

The second path is a local server. The README states that the IPs obtained by the local hosts service are tested locally, so the success rate is higher, and that it fetches the newest IPs on a schedule. The package.json shows what the server is built from: dependencies include dns-over-http, dns-over-tls, node-fetch, cheerio, lru-cache and portfinder. That mix suggests the server queries DNS over HTTPS and DNS over TLS, caches results in memory, and can fall back to another port if the requested one is taken. The README does not document the resolution order or the cache lifetime, so treat those as unknowns rather than assumptions.

## Installing hosts-server and making a first request

The README distributes prebuilt binaries through GitHub releases, tagged v1.0.1, and each platform has its own archive. On macOS with Intel silicon, the documented command downloads the archive, extracts it, clears the quarantine attribute, and starts the server on port 8888:

```bash
curl -L https://github.com/ineo6/hosts/releases/download/v1.0.1/hosts-server-pkg-mac-x64.tar.gz | tar xzvf -
xattr -d com.apple.quarantine ./hosts-server-pkg-mac-x64/hosts-server
./hosts-server-pkg-mac-x64/hosts-server --port=8888
```

The xattr step matters: without it, macOS may refuse to run the downloaded binary. On Apple Silicon the README gives the same shape without the quarantine command, and on Linux the archive names differ by architecture (linuxstatic-x64, linuxstatic-arm64, linuxstatic-armv7):

```bash
curl -L https://github.com/ineo6/hosts/releases/download/v1.0.1/hosts-server-pkg-linuxstatic-x64.tar.gz | tar xzvf -
./hosts-server-pkg-linuxstatic-x64/hosts-server --port=8888
```

On Windows, download the zip from the same release, extract it, and run the executable:

```bash
.\hosts-server.exe --port=8888
```

After that the service listens on http://localhost:8888. The README says the output is meant to be consumed either through SwitchHosts or by visiting the address and copying the text by hand. For the remote-file route, the documented SwitchHosts rule is a remote type with the URL https://gitlab.com/ineo6/hosts/-/raw/master/hosts and an automatic update interval of one hour. Once the rule is active, the entries appear in your system hosts file and GitHub should resolve through them.

If you would rather edit the file yourself, the README gives the locations: /etc/hosts on macOS and C:/windows/system32/drivers/etc/hosts on Windows. On macOS the documented cache flush is:

```bash
sudo killall -HUP mDNSResponder
```

On Windows it is:

```bash
ipconfig /flushdns
```

## Where ineo6/hosts breaks down

The clearest limitation is age. The last push to the repository was on 2022-04-23, and the newest release, v1.0.1, carries the same timestamp. The README's own generated block shows an update time of 2023-03-08, which is later than the repository's last push, so the published list and the repository history are not moving together. A hosts list is a snapshot of addresses that change; a snapshot with no recent regeneration is a liability, not an asset.

The second limitation is the trust boundary. Running hosts-server means executing a binary built by an individual and downloaded from a release page. On macOS the README's own instructions require removing the quarantine flag that Gatekeeper applies to downloaded software. That is a real decision, and the README does not describe a signing or verification step.

The third is scope. This tool rewrites name resolution for a fixed set of GitHub-related domains. It does not help with other slow sites, it does not encrypt traffic, and it does nothing for a network that blocks by IP rather than by name. If your problem is general connectivity rather than GitHub asset loading, a hosts file is the wrong instrument. The README also warns that the hosts address may change and tells readers to follow the GitHub and GitLab pages to stay current, which is an acknowledgement that any URL you hardcode can go stale.

## The alternative: let your resolver do the work

The obvious alternative is not another hosts list; it is a DNS resolver that already performs the same job continuously. Public resolvers and DNS-over-HTTPS clients resolve github.com through their own infrastructure and return an address chosen for the client's location, without you editing /etc/hosts or trusting a pinned IP. The difference in approach is centralisation versus local override: a resolver answers every query for every domain and adapts as records change, while ineo6/hosts freezes a mapping on your disk until something regenerates it.

The trade-off runs the other way too. A public resolver gives you no control over which address you get, and if the resolver's answer is the slow one for your network, you are stuck. A hosts entry lets you pin an address you have measured yourself, which is exactly the case the local hosts-server is built for. That is why the two paths in this project differ in quality: the remote file is someone else's measurement, while the local server is described as testing addresses on your machine.

## Maintenance, upgrades and the MIT licence

Upgrading means downloading a new release archive and replacing the binary; there is no package manager distribution documented in the README, and the npm package is named hosts-server with a bin entry pointing at bin/hosts-cli.js, but the README never tells you to install it with npm, so treat the release archives as the supported path. Configuration is limited to the --port flag shown in every platform example. The README does not document a config file, an environment variable, a service unit, or a way to run the server as a background daemon, so on Linux you would be supplying your own supervision.

The licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are kept. This is a permissive licence with no copyleft obligation. The README does not state which licence covers the generated hosts data as distinct from the code, so if you plan to redistribute the list itself, that is the question to check before you do. Nothing here is legal advice; read the LICENSE file in the repository.

## Conclusion

Adopt ineo6/hosts if you want a ready-made hosts file for GitHub and are comfortable running an unsigned binary that binds to localhost. Do not adopt it if you need a maintained project: the last push was on 2022-04-23 and the README itself notes the hosts address may change. Before relying on it, verify that the release asset for your platform still downloads, that the server answers on http://localhost:8888, and that the generated entries actually resolve on your network rather than assuming the published list fits your ISP.

## FAQ

### How do I use the ineo6/hosts file on Windows?

The README gives the hosts file location as C:/windows/system32/drivers/etc/hosts. Append the entries to that file and then run ipconfig /flushdns to clear the DNS cache.

### How do I use ineo6/hosts on a Mac?

The hosts file lives at /etc/hosts, and the README recommends SwitchHosts with a remote rule pointing at the GitLab raw URL and a one hour update interval. After editing, flush the cache with sudo killall -HUP mDNSResponder.

### How do I install the ineo6/hosts local server?

Download the release archive for your platform from the v1.0.1 release, extract it, and start the binary with --port=8888. The README lists separate archives for macOS Intel, macOS Apple Silicon, Linux x64, Linux ARM64, Linux ARMv7 and Windows x64.

### What port does the ineo6/hosts server run on?

Every platform example in the README passes --port=8888, and the text states the service runs at http://localhost:8888. The package.json also lists portfinder as a dependency, but the README does not document automatic port selection.

### Is ineo6/hosts still updated?

The last push to the repository was on 2022-04-23, and the newest release, v1.0.1, has the same timestamp. The generated block shown in the README carries an update time of 2023-03-08, so the published list and the repository history are not moving together.

## Sources

- [Official documentation](https://ineo6.github.io/hosts/)
- [Official README](https://github.com/ineo6/hosts#readme)
- [Project repository](https://github.com/ineo6/hosts)
- [Release notes](https://github.com/ineo6/hosts/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ineo6-hosts