ineo6/hosts: A Hosts-File Service for Faster GitHub Access, With a Maintenance Caveat

What This Project Actually Fixes

The problem is familiar to anyone using GitHub from a network where the default DNS returns slow or unreachable IP addresses. Images in repositories fail to load, and pages take a long time to respond. ineo6/hosts solves this by providing a curated hosts file that maps GitHub domains to IP addresses that are supposed to work better. The README states the direct effect: "GitHub图片可以正常加载，网页也稳定了," which translates to images loading normally and the web page being stable. The intended audience is GitHub users who are comfortable editing their system hosts file or using a tool like SwitchHosts. This is not a VPN or a proxy. It changes only the IP resolution for specific domains, leaving all other traffic untouched. The project also offers a local server that serves these mappings over HTTP, which is a more dynamic alternative to manually copying the file.

How the Hosts File and the Local Server Differ

There are two distinct mechanisms in this project. The first is a static hosts file hosted on GitLab, which you can fetch and append to your system hosts file. The second is a local server that runs on your machine and serves a hosts file over HTTP. The README explains that the local server's IPs are "经过本地测试," meaning they have been tested locally, so they have a higher success rate. It also claims the server periodically fetches the latest IPs to keep access working. The static hosts file, on the other hand, is updated on a schedule that is not clearly defined. The README shows a timestamp of 2023-03-08, but the repository's last push was in April 2022. That discrepancy is a red flag, and we will return to it. The local server is a compiled binary, not a Node.js script, despite the project being written in TypeScript. This means you do not need a runtime installed; you just download the binary and run it.

Getting It Running: Commands for Each Platform

The README provides direct commands for each platform. For macOS on Intel, you download a tarball, remove the quarantine attribute, and start the server on port 8888. The command is: curl -L https://github.com/ineo6/hosts/releases/download/v1.0.1/hosts-server-pkg-mac-x64.tar.gz | tar xzvf - followed by xattr -d com.apple.quarantine ./hosts-server-pkg-mac-x64/hosts-server and then ./hosts-server-pkg-mac-x64/hosts-server --port=8888. For Apple Silicon, you use the arm64 tarball and skip the xattr step. Linux x64 and ARM64 follow a similar pattern with static binaries. Windows users download a zip, extract it, and run .\hosts-server.exe --port=8888. The server listens on http://localhost:8888. You then point SwitchHosts to that URL, or you manually copy the content. The README also explains how to set up a remote rule in SwitchHosts with the URL https://gitlab.com/ineo6/hosts/-/raw/master/hosts and an automatic update interval of one hour.

The Maintenance Problem: Stale Releases and Inconsistent Updates

The most serious limitation is the maintenance status. The latest release is v1.0.1, published on 2022-04-23. The repository's last push is the same date. Yet the README, which was presumably edited later, shows an update timestamp of 2023-03-08 for the remote hosts file. That means the hosts file content might be newer than the release binaries, but the binaries themselves have not been updated for over a year. If GitHub changes its IP ranges, the local server binary will still work, because it fetches the latest hosts content, but the static hosts file URL might change without a corresponding release. The README warns that "hosts地址可能会调整," meaning the hosts address may change, and urges users to follow the GitHub and GitLab pages. This is a real operational risk. If you rely on the static file, you must periodically check the project page for new URLs. The local server mitigates this because you can point SwitchHosts to the server, and the server is supposed to fetch updates, but the server's update logic is not documented in the README. You cannot verify how often it refreshes.

Security and Trust Considerations

Modifying your hosts file means you are trusting the project to provide correct IP addresses. A malicious or compromised hosts file could redirect GitHub traffic to a phishing server. The project is MIT licensed and appears to be a personal project by one developer. The README asks users to "Please Star" the repository, which is a common request but not a quality signal. There is no mention of any verification mechanism, such as checksums or GPG signatures, for the hosted hosts file. The local server binary is distributed as a tarball or zip, and there is no checksum provided in the README. This is a genuine concern for security-conscious users. The project's reliance on GitLab as a mirror adds another point of trust. If the GitLab mirror is compromised, the hosts file could be altered. The README also mentions a WeChat public account, which is a non-technical dependency that might not be accessible to all users.

Alternatives: How They Differ in Approach

A common alternative is to use a DNS-based service like Google Public DNS or Cloudflare 1.1.1.1, which may resolve GitHub to faster IPs depending on your location. The difference is that DNS services operate at the resolver level, so they affect all domains and require no hosts file changes. They are also maintained by large organizations with clear uptime guarantees. Another alternative is to use a GitHub mirror or a proxy service, but those often require installing additional software or changing git remote URLs. The most direct comparison is with other hosts-file projects, such as the well-known "googlehosts" or "hosts" repositories that aggregate mappings for many services. Those projects often have more frequent updates and a larger community, but they also require manual merging of many entries. ineo6/hosts is narrower in scope, focusing only on GitHub, which makes it simpler but also less flexible. If you need to speed up GitLab as well, the README mentions that it supports GitLab, but the hosts file content is not shown in the provided material, so you cannot confirm which domains are covered.

What the Repository Does Not Tell You

The README is written entirely in Chinese, which is a barrier for non-Chinese readers. That is a real limitation for a tool that is meant to be used globally. There is no documentation of the internal architecture, such as how the local server fetches updates or how the IPs are selected. The project is written in TypeScript, but the release binaries are compiled, so you cannot easily inspect the source behavior without cloning the repository. The README provides a link to the source on GitHub, but the provided material does not include any source code details. There is also no information about error handling. If the local server fails to fetch new IPs, what happens? The README does not say. The project has no obvious command-line options beyond --port, so you cannot configure a different update interval or a custom upstream URL. These gaps make it difficult to assess reliability beyond the basic use case.

Editorial conclusion

Adopt ineo6/hosts if you are a GitHub user in a region with slow or blocked access, especially if you want a simple, no-install solution that works on macOS, Linux, or Windows. Do not adopt it if you need guaranteed freshness, since the repository has not had a release since April 2022 and the remote hosts file's update timestamps are inconsistent. Before relying on it, verify that the IP addresses in the current hosts file actually resolve to the expected GitHub servers, and check the GitHub and GitLab pages for any announced address changes. If you need more control, consider running the local server with SwitchHosts, but be prepared to monitor updates yourself.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes