airport-free rebuilds a free node subscription with GitHub Actions every three hours

The output is text files, not a service you connect to

The repository produces subscription files and nothing else. At the top level there is a v2ray.txt file alongside clash/ and v2ray/ directories holding the individual node lists, a nodes/ directory with the scripts, an image and the readme. The main entry point is described as a v2ray nodes all in one file, with a note that it is not recommended, and a second all-in-one link that is offered for readers who cannot reach the first. A separate set of links serves the clash files, split into three groups for each protocol, so a subscriber can pull one smaller file rather than everything. The important structural point is that nothing here is a running server. You fetch a text file of node definitions and hand it to a client, and the client is what actually talks to the servers. The readme also carries an update timestamp in UTC+8, which tells you when the files were last rewritten and is the first thing to look at when a subscription seems stale.

A GitHub Actions workflow is the whole update mechanism

The regeneration is described in the Peculiarity section, and the mechanism is a GitHub Actions workflow. For the v2ray output you save the Python script to the node/v2/ directory, go to the action, run the workflow, and you can see the output result; for clash the same with the script in node/clash/. The scripts are the actual scrapers, and the workflow runs them and writes the result into the repository, which is what the CDN then serves. That is a small and legible pipeline, and it has an obvious property worth naming. Because the output is committed to a git repository and served as a static file, the whole thing is reproducible and inspectable, and the history of the files is a record of what the scrapers found over time. The same design also means there is no coordination server and no availability guarantee, since the service exists only for as long as the workflow keeps running and the sites it reads keep answering.

CDN acceleration and update lag are the same problem

The readme documents a tension that anyone using this kind of repository hits immediately. The public links go through the jsDelivr CDN, which is what makes them fast and reachable from networks where GitHub is slow. The same readme warns that CDN acceleration will cache and cause node updates to lag, and the remedy it offers is to go to the GitHub repository directly and fetch the clash files or the v2ray files. The lazy cache is not a bug in the CDN, it is the behaviour a CDN is supposed to have, so the practical question is how stale a node list is acceptable to you. The readme also records an update time in UTC+8, which is the reference point for judging freshness, since a file served from a cache can carry a timestamp that no longer matches the nodes inside it. For a reader on a slow network the mirror links exist for the same reason, and the note about them says the second all-in-one link can be used if the first is not accessible.

The mirror table is a second distribution path for blocked networks

The readme has two nearly identical tables, one for jsDelivr and one for a proxy front, and the reason is stated in the section heading: if you cannot access it, please access it through the other route. The mirror table covers the same six files, three v2ray groups and three clash groups, and the difference is only the prefix on the URL. This matters more than a duplicate set of links normally would, because the audience for this repository is exactly the people most likely to have GitHub or jsDelivr partially blocked or throttled. It is worth being blunt about the trade-off, since the mirror route depends on the proxy service remaining free and reachable, and the readme does not claim otherwise. Both routes serve the same underlying files, so the mirror does not fix a stale cache, it only fixes an unreachable host.

The node sources are contributed through issues

The project is open to new sources by a mechanism that is worth noting because it shapes how the collection grows. The readme says the source code has added a few node sources by default, that it automatically detects updates every three hours, and that if there is a new source you are welcome to go to the issues section to submit it. So the pipeline is scraper first and community second, and the contribution path is an issue rather than a pull request, which is unusual but consistent with a repository where the committed artefacts are generated. The rest of the repository is described as open, with the sources available in the main branch, and the readme instructs maintainers on where to edit the file that generates the readme itself, at nodes/README.md. That detail says something about the setup, because a readme that is itself generated has to be regenerated along with the node lists, and the update time at the top is part of that generation.

Deduplication is best effort, and the readme says so

The issues section contains the most useful warning in the whole document. Due to the possibility that some of the nodes included in multiple websites may be duplicated, deduplication has been done, but there may still be some duplicates. In other words, the scraper merges several sources and tries to remove overlap, and the author does not claim the result is clean. That has a practical consequence for a client, since a subscription with duplicate entries makes a node list longer and noisier, and some clients will show the same server under two names. There is also a second warning in the same section: some websites may not be accessible in the future due to the GFW or the site itself, which may result in the inability to renew the subscription. A source that stops answering is not an error the pipeline can recover from, because the whole point of the workflow is to fetch and publish, and a source that no longer responds simply stops contributing.

Where airport-free is the wrong choice

The first wrong case is any use that needs a service with an accountable operator, because nothing here is operated, the entries are scraped from sites whose ownership is unknown, and the maintainer says in the Tips that all data comes from the Internet and that users are required to identify the authenticity of the content. The second is a production or corporate deployment, since the node set is opportunistic, the readme names the GFW as a reason sources disappear, and a client configured from these files has no continuity guarantee. The third is a reader on a network where the mirror service is also blocked, in which case neither the CDN nor the mirror resolves the problem, and the readme offers no third route. The fourth is anyone who needs a specific server rather than a sample, since the list is regenerated wholesale every three hours and a node that is useful today may be absent tomorrow. The fifth is a developer looking for a proxy implementation to study, because the interesting part of this repository is the scraping and publishing pipeline rather than any proxy technology, and the scripts under nodes/ are the only code here.

Editorial conclusion

People who want a ready-made v2ray or clash subscription to try out, and who understand that the entries are scraped from third-party sites and may stop working at any time, are the people airport-free serves, and the three hour refresh cycle with committed output files is what makes it usable at all. It is the wrong choice for anyone who needs a stable, accountable service, because the maintainer says as much in the issues section, and it is the wrong choice for a deployment that cannot tolerate nodes that appear and disappear without notice. Check three things before you point a client at it: that your client accepts the subscription format you pick, since the repository publishes both a v2ray text file and separate clash files, that the CDN path you choose serves the current file rather than a cached one, since the readme warns that CDN acceleration caches and makes node updates lag, and whether you have a fallback ready, since the maintainer notes that some source sites may become unreachable and the subscription will then fail to renew. The licence is not stated in the repository metadata, the last push was on 2026-09-23, and the repository publishes no releases.

Frequently asked questions

Official sources

1. Issues
2. README
3. xiaoji235/airport-free on GitHub