# ProxyNodeHub finds free proxy subscription repos on GitHub and merges them

> ProxyNodeHub is a Windows desktop tool and an ASP.NET Core web workbench that searches GitHub for active repositories publishing free proxy nodes, scores them for activity, probes them for subscription links, deduplicates the nodes by server and port and exports a usable subscription. It suits people who want one consolidated list instead of checking repository after repository, and its Docker image is built for amd64 hosts only.

**wanvfx/ProxyNodeHub** — ProxyNodeHub 用于发现 GitHub 上活跃的免费节点仓库：分析活跃度、去重分散的节点、直接给出可用的订阅链接。点一次「搜索并分析」，剩下的梳理工作全部由它完成。

- Repository: https://github.com/wanvfx/ProxyNodeHub
- Stars: 527 · Forks: 85
- Language: C#
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/wanvfx-proxynodehub

## The problem: one repository at a time, and a list that never stays current

The project's description states the problem in one line: discovering active free node repositories on GitHub by analysing activity, deduplicating the scattered nodes, and directly producing usable subscription links. One click on search and analyse, and the sorting work is done for you.

The README expands on why that work is worth automating. Instead of going through repositories one by one, comparing them and hand-assembling a subscription, the tool picks out the repositories that update most often and are maintained most steadily, merges and deduplicates them, and exports once. It also surfaces repositories that are tucked away in corners and easy to miss, with the observation that in the free node field a low profile repository often means low load and a long life, which is where the genuinely useful nodes are.

That is the whole value proposition, and it is a maintenance problem rather than a technical one. The set of repositories publishing free nodes changes constantly: some go quiet, some get taken down, some start publishing garbage. A list assembled by hand is wrong within days.

So the intended user is someone who already trusts community-published free nodes and wants the aggregation handled for them. It is not a tool for choosing a VPN provider, and the README does not make any claim about the safety or the ownership of the nodes it finds. It is an aggregator, and the trust decisions stay with whoever consumes the output.

## Six probe layers, eight concurrent searches and a hundred point score

The feature table describes the Windows client, and the discovery machinery is where most of the engineering sits.

The six layer probing engine works in order: a feature library that learns, a hardcoded mapping, file tree filtering, probing of common paths, README parsing, and a fallback candidate step. The learning layer is the interesting one. Once a path has successfully produced a subscription for a given repository, the tool remembers it, so the next search of that repository tries the known path first and goes faster.

Search itself is concurrent, with eight keywords queried in parallel against the GitHub REST API. Activity scoring combines commit frequency, evenness of commits, automation signals and how hidden the repository is, on a hundred point scale. That combination is a proxy for whether a repository is genuinely alive, and the evenness term is the part that catches a repository which commits in bursts rather than steadily.

Deduplication keys on server:port, and the merged result becomes one exported subscription. Four processing modes are offered, each with its own concurrency level: a fast mode, a standard mode, a deep mode and a compatibility mode. The differences matter because deep probing is slow enough that it is not something you want on every search.

The remaining features are operational. An automatic proxy layer with thirteen acceleration mirrors does its own speed test, falls back when a mirror fails, and caches results for five minutes. Search history filtering skips repositories you have already searched, with a configurable window from one to thirty days. Favourites have their own view and survive a restart. Logging is written to disk with rolling retention and a one-click cleanup.

The README is clear that the Docker web version reuses the discovery and analysis core and provides discovery, filtering, favourites, export, task records, scheduling and external subs-check control, without starting the desktop shell or a second speed test kernel.

## Two builds for Windows, one optional token stored in plain text

The runtime requirements section offers two Windows builds, both for Windows 10 and above on x64.

The self-contained build needs no runtime installed at all. The framework-dependent build requires the .NET 8 Desktop Runtime. The quick start is three steps: take the build package from the releases page, choosing ProxyNodeHub_v0.0.1_self-contained.zip when you have no prerequisites, unzip it into any directory, run ProxyNodeHub.exe, and press F5 or click the search and analyse button to start.

The GitHub token is optional, and the README is unusually explicit about how it is handled. The desktop client currently stores it in plain text in a settings.json file in the same directory as the executable, and that file is not encrypted with the Windows Credential Manager, so it should not be committed or shared. The search API has its own separate limit, and the actual limit is whatever GitHub's response says.

That plain-text token is the first thing to weigh. A token is optional for the search to work, so if you are running the desktop client on a shared or managed machine, leaving it unset is the safer default, and adding a token means treating the directory containing the executable as sensitive.

The repository also carries a Windows build script, build.ps1, and a solution file ProxyNodeHub.slnx, alongside the src/ directory holding the WinForms client, core/ for the shared logic and web/ for the ASP.NET Core service.

## The Docker web workbench, and the parity gap it documents

The web version is a separate ASP.NET Core service rather than a remote desktop. The browser handles the interaction, the container handles discovery, scheduling and persistence, and closing the page does not stop the background tasks.

The README lays out three code paths and what each is for. The Windows client lives in src/ with WinForms on .NET 8 and is meant for searching, exporting and managing a local speed test kernel on your own machine. The Docker web version lives in web/ on ASP.NET Core with .NET 10, and is for several devices on a LAN reaching one workbench with scheduled discovery and centralised results. The shared core lives in core/ and holds GitHub search, repository scoring, subscription probing, parsing and learning, and it is reused by both ends so the discovery logic is not maintained twice.

The web interface offers six entry points: repository discovery, favourites, subscription checking, run records, learning records and service settings. It supports filtering and sorting, bulk favouriting and re-checking, export by scope, online configuration of the GitHub token and the checker connection, and persisted discovery schedules.

What it does not have is stated just as clearly. Local kernel install and upgrade, complete checker YAML editing, and per-round history replay were not carried over into the web version, and the README points at a full parity review document for the covered capabilities and the differences. That honesty is worth having, because it means the web deployment is a different tool from the desktop one rather than the same tool in a browser.

The images are published on Docker Hub, and the CI workflow is linked for checking that the image for a given commit was built successfully. The current image supports linux/amd64 with the .NET 10 runtime built in, so the host needs no .NET installed, and no ARM64 image has been published.

## Running the container, and the pins that matter

Pulling the image does not require cloning the source or installing .NET on the server:

```sh
docker pull helloworldz1024/proxynodehub:latest
```

The tag latest points at the most recently pushed successful image and is not guaranteed to match the current GitHub commit, so the README recommends pinning with a sha-<full commit> tag for production upgrades. To build the image yourself, you run docker build -t proxynodehub:local . in the source root, and the root Dockerfile is the service image rather than the one in tests/.

The persistent directories and the administrator password file have to be prepared once, and the README is careful to say the command does not overwrite an existing password:

```sh
mkdir -p /mnt/usb1-1/proxynodehub/data /mnt/usb1-1/proxynodehub/secrets
test -e /mnt/usb1-1/proxynodehub/secrets/admin-password || \
  (umask 077; openssl rand -base64 -out /mnt/usb1-1/proxynodehub/secrets/admin-password 32)
chown -R 1654:1654 /mnt/usb1-1/proxynodehub/data /mnt/usb1-1/proxynodehub/secrets
chmod 750 /mnt/usb1-1/proxynodehub/data /mnt/usb1-1/proxynodehub/secrets
chmod 600 /mnt/usb1-1/proxynodehub/secrets/admin-password
```

The user id 1654 and the permission bits are not arbitrary. The Dockerfile creates the data directory and chowns it to 1654:1654, runs the container as USER 1654:1654, sets DATA_DIR=/data and ASPNETCORE_HTTP_PORTS=8080, and the healthcheck hits http://127.0.0.1:8080/live every thirty seconds with a five second timeout.

The example paths assume /mnt/usb1-1/proxynodehub, and the README notes that other hosts should substitute their own paths and that data should not be stored under /script.

One naming point catches people out. The subs-check service is an optional, separate detection service that is not bundled in the image, and the file /subscriptions.txt is the list of source URLs handed to the checker, not a speed tested node subscription.

## Where ProxyNodeHub is the wrong tool

There are three honest limits, and one of them is about the nature of the nodes rather than the software.

The first is that the output is only as good as the public repositories it scans. These are community-maintained lists of free proxies, and the README makes no claim about their provenance, ownership or safety. Anyone consuming the output inherits the risk that a published endpoint is hostile, and the tool's own features, such as the automatic mirror acceleration with its speed testing, are about reachability rather than trust. If your threat model does not tolerate traffic going through an unknown endpoint, this category of tool is the wrong category regardless of how well the aggregation works.

The second is the feature gap between the two editions. The web workbench lacks local kernel installation and upgrade, complete checker YAML editing and per-round history replay, and the README is explicit that not counting a jump to an external management console as implemented counts as a difference. If your workflow depends on any of those, the desktop client is the only one that has them.

The third is platform coverage. The current Docker image is linux/amd64 only, the host needs no .NET, and no ARM64 image has been published. On an ARM host, such as an Apple Silicon machine or a modern ARM NAS, the container image will not run as published, and you are back to the Windows client or building for your own architecture.

For comparison, the alternatives differ in approach. A subscription client with a manually maintained list of repository links is the simplest option and has no code to run, but the list rots and the deduplication is on you. A general purpose aggregation script run on a schedule gives you the same discovery with a different implementation, and you maintain the probing logic yourself rather than inheriting the feature library learning and the mirror fallback that this tool provides. A commercial proxy or VPN provider is a different purchase entirely, with a different set of guarantees and a different cost.

Within the aggregation category, ProxyNodeHub is the more complete option, and its cost is that you are running a service that talks to GitHub on your behalf and holds a token that grants access to your account.

## Conclusion

Adopt ProxyNodeHub if you already rely on community-published free proxy repositories and want a single deduplicated export instead of maintaining a list by hand, since the discovery, scoring, probing and export steps are all automated and the shared core is reused by both the desktop client and the web workbench. Do not adopt it as a privacy or reliability guarantee, because the nodes it finds are public and frequently short lived, and note that the free client stores the GitHub token in plain text. Before you deploy the web version, read the parity review linked in the README, because the maintainers state that local kernel install, full checker YAML editing and per-round history replay were not carried over. The licence is MIT, the release is dated 20261005, and the last push was on 2026-10-08.

## FAQ

### What does ProxyNodeHub do?

It discovers active free proxy node repositories on GitHub, analyses their activity, deduplicates the scattered nodes and produces usable subscription links directly. The README frames it as replacing the need to browse, compare and manually assemble subscriptions from repository after repository.

### How do I run the ProxyNodeHub Windows client?

Take the build package from the releases page, choosing ProxyNodeHub_v0.0.1_self-contained.zip if you have no prerequisites, unzip it to any directory and run ProxyNodeHub.exe, then press F5 or click the search and analyse button. The self-contained build needs no runtime, while the other build requires the .NET 8 Desktop Runtime.

### Is a GitHub token required for ProxyNodeHub?

No, the token is optional. The desktop client stores it in plain text in a settings.json file next to the executable, which is not encrypted with the Windows Credential Manager, so the file should not be committed or shared, and the search API has its own separate limit set by GitHub.

### How does ProxyNodeHub deduplicate the nodes it finds?

It keys on server:port and merges the result into a single exported subscription. The discovery side searches GitHub with eight keywords concurrently against the REST API and scores each repository out of a hundred using commit frequency, evenness, automation and how hidden the repository is.

### What are the differences between the ProxyNodeHub Docker web version and the Windows client?

The web version reuses the discovery and analysis core but does not start the desktop shell or a second speed test kernel, and local kernel install and upgrade, complete checker YAML editing and per-round history replay were not carried over. The README points at a parity review document listing what is covered and what differs.

### Which platforms does the ProxyNodeHub container support?

The current image supports linux/amd64 with the .NET 10 runtime built in, so the host needs no .NET installation, and no ARM64 image has been published yet. The Windows client supports Windows 10 and above on x64.

## Sources

- [Issues](https://github.com/wanvfx/ProxyNodeHub/issues)
- [License: MIT](https://github.com/wanvfx/ProxyNodeHub/blob/main/LICENSE)
- [README](https://github.com/wanvfx/ProxyNodeHub/blob/main/README.md)
- [Releases](https://github.com/wanvfx/ProxyNodeHub/releases)
- [wanvfx/ProxyNodeHub on GitHub](https://github.com/wanvfx/ProxyNodeHub)

---

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