A 2-hour job replaces normal DNS answers with chosen IPs
GitHub520 takes a direct approach to unreliable GitHub access. Its workflow runs every 2 hours, retrieves a generated address list, and republishes a hosts file covering GitHub pages, raw files, release assets, avatars, Copilot, and related domains. A user then makes the operating system prefer those addresses over ordinary DNS. That can repair a broken route quickly, but it also makes the feed's address choices part of every GitHub connection on that machine.
The user path is short. The Chinese README says it takes 5 minutes and offers manual copying, one-line commands, SwitchHosts, and an AdGuard route. Windows, Linux, and macOS each get a DNS-cache command. SwitchHosts is the saner desktop option because the change has a visible profile and a recommended 1-hour refresh interval. On iOS the README requires jailbreaking, and on Android it requires root, which rules out most managed phones.
A 30-second source install is separate from the user setup
Our clone of commit 03874f6 had 17 files, about 332 lines of source, and a 1.5 MB checkout. Installing its Python environment took 30 seconds, added 61 packages, and consumed 57 MB. The build succeeded in 3 seconds. Those figures describe development of the address generator. Someone subscribing to the generated hosts file does not install those packages or run the Python scripts.
The distinction matters because the README's no-install claim is fair for its normal audience. A user needs the raw hosts URL and permission to change system networking. A contributor inherits a Python resolver that queries several DNS-over-HTTPS and DNS servers, tests candidate addresses over TCP port 443 three times, chooses the lowest median latency, and writes both text and JSON output. No API credential appears in that path.
What happened when we ran it
Our sandbox installed GitHub520 in 30 seconds and built it in 3 seconds on 3 CPUs with 8 GB of RAM. The unprivileged Debian container used Python 3.12 and had no secrets. Installation and build both completed. Pip-audit found 12 known vulnerabilities in the resulting 61-package environment, so contributors should inspect and update the dependency set before trusting the generator in a sensitive workflow.
There was no test script or target at commit 03874f6, so our harness skipped tests. The repository had 1 CI workflow and no tests directory or Dockerfile. A green scheduled workflow therefore shows that the update script ran. It does not give us unit coverage for DNS failures, certificate mismatches, malformed payloads, or hosts-file replacement. We did not measure browsing speed, route quality, or uptime, and the 3-second build cannot answer those questions.
The checkout itself was only 1.5 MB, but its output changes a privileged system file. That is the practical risk boundary. Keep a clean copy of the previous hosts block, inspect the new mapping, and know how to flush the local DNS cache. The project's GNU command truncates the managed tail and appends the remote response, so an interrupted or bad fetch deserves more care than a normal application update.
commit 03874f6 chooses latency before certificate identity
The updater connects to every candidate on port 443 three times and chooses the IP with the lowest median TCP latency. It does not validate that the server presents a certificate for the requested GitHub hostname. Open PR 319 was created to add TLS and SNI validation after issue 310 documented a certificate mismatch. Until that check lands, a fast TCP handshake is too weak a standard for unattended fleet-wide publication.
Issue 324 adds a different warning for AdGuard Home users. The reporter imported the hosts feed as a DNS blocklist and then saw ERR_CONNECTION_TIMED_OUT on a phone and Windows 11 PC. Their investigation found an IPv4 answer plus an all-zero IPv6 response. That report covers one setup, so it does not prove a general AdGuard defect. It does show that the README's blocklist method needs a small-device trial before network-wide use.
The October push includes automation, while 17 issues remain open
GitHub recorded a push on October 7, 2026, and the latest open issue was created on October 4. The open queue contained 17 issues and 7 pull requests. That is current activity, but the repository's scheduled 2-hour publishing job can also move the default branch without a maintainer changing the selection logic. Issue and pull-request dates are more useful health signals than the push date by itself.
GitHub returned no latest release, and the project has no test target in our measured commit. The README labels the project as being in a test stage and says it has only been tested on the author's machine. Its license notice is CC BY-NC-ND 4.0, while GitHub's repository metadata identifies no standard software license. Personal use is easy to understand. Modification and commercial redistribution need a much more careful license reading.
Use the 5-minute fix only where rollback is easy
GitHub520 can be useful when one developer cannot load GitHub and can restore a hosts file without help. I would keep it on an individual workstation, refresh it through a visible profile, and remove it as soon as normal routing works. A company-wide DNS layer deserves certificate-aware address checks, automated validation, a tested failure path, and licensing that clearly covers modified operational use. commit 03874f6 does not meet that bar.