FreeSubsCheck: A GitHub Actions Pipeline That Publishes Fresh Proxy Subscriptions as Static Files

What FreeSubsCheck Actually Solves

FreeSubsCheck solves a narrow problem: getting a set of free proxy subscription links that are periodically refreshed without manual effort. The repository does not host any proxy infrastructure. It aggregates nodes from public sources, runs a checker called subs-check, and publishes the results as static files in the repository. The target audience is people who want a quick, no-cost way to obtain proxy nodes for clients like Clash, Mihomo, or other software that accepts Base64 subscriptions. It is also a teaching resource: the README explicitly states the project is a technical demonstration of GitHub Actions automation and YAML data processing. If you are an engineer evaluating whether to build your own subscription aggregator, this repo shows one possible end state: a set of generated files that clients can fetch directly from raw.githubusercontent.com.

The Mechanism: subs-check, GitHub Actions, and Static Output

The pipeline is driven by two external components: subs-check (from beck-8/subs-check) and GitHub Actions. The README states that the data source is blog.kooker.jp, and the repository also includes files named byxiaoxi.txt and kooker.jp.txt, indicating multiple upstream feeds. subs-check appears to crawl or fetch node lists from these sources, test their availability, and then write the results into several formats. The repository layout shows four subscription files: mihomo.yaml for Clash Meta, all.yaml for standard Clash, base64.txt for generic clients, and two TXT files that appear to be raw node lists from specific sources. The automation runs on a schedule, as evidenced by the timestamp in the README ('2026-08-29 16:00:39'). The output is static, meaning clients download the files directly from GitHub's raw content domain. There is no server-side logic after the Action completes; the entire system is a batch job that commits updated files back to the repository.

Getting It Running: What You Actually Do

You do not install FreeSubsCheck. You consume its output. The README provides five subscription URLs, all pointing to raw.githubusercontent.com under the kooker/FreeSubsCheck repository. For a Clash Meta client, you would add the mihomo.yaml URL. For standard Clash, you use all.yaml. For a generic client that accepts Base64-encoded node lists, you use base64.txt. The two TXT files are alternatives that contain node lines only, likely in a format that some clients can import directly. To run the pipeline yourself, you would need to fork the repository, set up GitHub Actions with a schedule, and configure subs-check to fetch from your own sources. The README does not include a setup guide, so you must refer to the subs-check project for configuration details. The repository itself is a demonstration of output, not a documented tool for building your own pipeline.

The Numbers: What 638 Nodes Actually Means

The README reports node counts: 7 from SubsCheck, 3 from XiaoXi, and 628 from kooker.jp. That is a total of 638 nodes at the time of the last sync. These numbers are snapshot values, not guarantees. The count can drop dramatically if upstream sources disappear or if subs-check filters out dead nodes. The discrepancy between the sources is notable: kooker.jp provides the bulk, while the other two contribute almost nothing. This means the subscription quality is entirely dependent on a single upstream source. If blog.kooker.jp stops publishing or changes its format, the subscription becomes nearly empty. The README itself warns that nodes may become invalid or blocked at any time. Treat the node count as a point-in-time metric, not a promise of availability.

A Real Limitation: No Verification, No Security Guarantees

The most serious limitation is the lack of any security guarantee. The README's disclaimer states that the project does not warrant stability, effectiveness, or safety, and it explicitly warns that third-party nodes may perform traffic auditing or logging. That is not a hypothetical risk; it is a known property of public free proxy services. Anyone using these nodes for privacy-sensitive traffic is exposing themselves to potential interception. The project also does not provide any way to verify the identity of the node operators. The subs-check tool presumably tests connectivity, but it cannot test trustworthiness. For engineers, this means FreeSubsCheck is unsuitable for any use case that requires confidentiality or integrity of traffic. It is also unsuitable as a reliable infrastructure component, because the node list can change without notice and contains no SLA. If you need a stable proxy endpoint, you should run your own server or pay for a commercial service.

The Wrong Tool for Production, the Right Tool for Testing

FreeSubsCheck is the wrong tool if you need dependable connectivity for business applications. The nodes are free, public, and ephemeral. There is no monitoring, no support, and no guarantee that any specific node will be online at a given time. The project is also legally risky in some jurisdictions, as the disclaimer itself notes that users must ensure their usage complies with local laws. However, it can be the right tool for testing client configurations. If you are developing a Clash or Mihomo setup and need a quick way to generate a large number of nodes to test load balancing or failover logic, this subscription provides a convenient source of test data. The static files are easy to fetch and parse, and you can run your own checks on them. Just remember that the data is not curated, so your tests will be against a noisy, uncontrolled dataset.

Alternatives: Build Your Own Aggregator or Use a Commercial Provider

The natural alternative is to run your own subs-check pipeline. The README credits beck-8/subs-check as the engine, and that project is designed to be self-hosted. With your own instance, you control the upstream sources, the filtering rules, and the output formats. You also avoid the dependency on a single maintainer's schedule. The trade-off is that you must handle the operational overhead: setting up a cron job or GitHub Action, monitoring for source changes, and dealing with broken parsers. Another alternative is to subscribe to a commercial proxy service, which provides stable nodes, customer support, and usually better performance. The difference in approach is fundamental: FreeSubsCheck is a batch aggregation of public data, while a commercial service is a managed infrastructure with its own servers. If you want control and are willing to maintain the pipeline, build your own. If you want reliability, pay for it.

Maintenance and License: What You Are Not Told

The repository metadata shows no license, which is a problem if you plan to fork or reuse the code. Without a license, you have no explicit permission to copy, modify, or distribute the repository's contents, even if the README suggests it is a demonstration. The README itself is written in Chinese and includes a disclaimer that appears to be a legal notice, but it does not grant any open-source license. The project is not archived, but the last push date is unknown, and there are no recent releases. This suggests the repository may be updated on a schedule via GitHub Actions, but the maintenance status is unclear. The README includes a timestamp that is in the future relative to the current date, which is odd and suggests the project may have been created as a template or that the clock is not reliable. For any serious use, you should check the repository's commit history and license file directly. If you intend to build on this project, you should contact the maintainer or choose a differently licensed project.

Editorial conclusion

Adopt FreeSubsCheck if you want a concrete example of using subs-check and GitHub Actions to produce static subscription files, or if you need a quick source of free nodes for testing client configurations. Do not adopt it for production or privacy-sensitive traffic: nodes are unverified, may be blocked at any time, and the README warns about potential traffic auditing. Before relying on it, verify the freshness of the generated files, check whether the upstream sources (blog.kooker.jp, XiaoXi, kooker.jp) are still active, and confirm that the generated YAML and Base64 files match the expected format for your client. The project is a demonstration, not a service, so treat it as a reference for automation patterns, not as a dependable node provider.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases