CFNext subscription management on Cloudflare Workers and Pages

CFNext's subscription panel and routing scope

CFNext addresses the operational work that appears after a proxy node has been deployed: assembling usable nodes into subscriptions, filtering those nodes, and delivering output in formats understood by different clients. The repository describes it as a multifunction proxy subscription management panel deployed on Cloudflare Workers or Pages. Its default interface is reached through `/UUID`, or through a custom path, while `/sub` produces the subscription. This split separates browser administration from machine-oriented subscription delivery.

The target users are operators who manage their own Cloudflare configuration and want one JavaScript file to combine proxy handling and a graphical panel. The project supports VLESS, Trojan, and XHTTP. It also recognizes client-specific output needs, including Clash YAML, sing-box JSON, Karing output, and generic text configurations. The panel lets an operator constrain nodes by protocol, region, carrier, and IP version rather than publishing an undifferentiated source list.

This is not a general reverse proxy dashboard or a consumer proxy client. Its center of gravity is subscription construction and node routing around Cloudflare. Operators still need to understand what the generated configurations instruct their clients to do. CFNext selects and packages proxy nodes, but the README does not establish that it replaces the need to secure the Cloudflare account, protect panel access, or validate each upstream source.

Routing from panel settings to subscription responses

The documented architecture is a single-file JavaScript application whose routes combine management, subscription generation, and proxy routing. KV stores persistent configuration and selected runtime state. The README states that changing settings after KV is bound takes effect without rebuilding the application. It also documents environment variables that can override stored values, including `ADMIN`, which can forcibly replace the KV password, and `login`, which determines the login route.

Node selection is more involved than simply copying a remote list. CFNext can pull preferred-node sources, preserve original node names, apply protocol and geographic filters, and generate output for the requesting client. A country can be identified from a node name, while the release notes also describe landing-point self-learning for nodes whose region cannot be recognized from the name. A subscription request can temporarily override country selection through query parameters such as `?country=XX` and `?country=off`.

Proxy routing supports direct outbound behavior, built-in regional fallback, configured ProxyIP sources, and home or carrier-oriented nodes. From version 2.8.0, ProxyIP can contain several entries separated by commas, semicolons, or newlines. Entries carrying a two-letter country code are assigned only to nodes landing in that country. Unqualified entries act as general candidates, and an unmatched node falls back to the first entry. Domain names and literal IPv4 or IPv6 addresses are accepted. Brackets are required around an IPv6 literal, such as `[2001:db8::1]:443`.

The routing logic is feature-rich, but it also makes CFNext more sensitive to configuration than a simple static subscription generator. A country mismatch, unavailable landing source, or unintended source URL can affect the nodes a client receives. Administrators should therefore treat the source list, routing mode, country filters, and ProxyIP ordering as one configuration rather than editing them independently.

KV settings, quota controls, and write pressure

KV is more than an optional convenience in CFNext. It retains the panel password and configuration, participates in landing-point self-learning, stores cache snapshots, and supports deduplication records for rotating subscriptions. The README says that binding KV allows configuration changes to take effect immediately. That convenience comes with write costs, and recent release notes devote substantial attention to limiting unnecessary writes.

The documented budget allows cache-like writes up to 300 times per instance per day. Once that budget is exhausted, CFNext skips those writes and reloads the affected cache later. Landing-point records are time-gated to at most one write per account every 60 minutes. Subscription rotation deduplication also has a 30-second protection against rapid retries. When rotation is enabled, each update writes to KV, and the panel advises a client update interval of at least five minutes.

Quota behavior has two documented policies. The existing policy begins reducing output when daily usage exceeds 60 percent. Strict mode instead stops all node delivery above 95 percent, returns HTTP 403 with a message, and resumes on the next day. If strict mode is enabled, it overrides proportional reduction after the threshold is crossed. Separately, subscription requests are limited to 10 per minute and panel requests to 20 per minute using an in-memory token bucket, with HTTP 429 and `Retry-After` when exhausted.

KV is eventually consistent rather than a transactional configuration database, but this README does not describe how that consistency model affects every setting. It also does not provide a formal backup or rollback procedure. Operators should not assume that toggling a panel value and immediately reading it from every location will behave like a transaction.

Obtaining CFNext and completing a first deployment

The repository does not provide a conventional package-manager installation command, command-line installer, or copy-and-paste Cloudflare configuration. Its top-level artifacts include the following files and archive:

CFNext-明文版.js

This block names the plain JavaScript artifact, not an executable command. Other repository entries include `CFNext-混淆版.js`, `CFNext-小说混淆版.js`, and `CFNext-混淆Pages版.zip`. The README links to deployment and usage videos, but the visible instructions do not document the exact dashboard choices, bindings, secrets, or configuration values required for a first deployment. This article therefore does not invent commands or deployment steps.

The first operational step must be performed through the repository and linked deployment guidance. Choose the build relevant to the intended Cloudflare environment, then compare that choice with the version-specific documentation. The release notes distinguish plain JavaScript, obfuscated JavaScript, novel-style obfuscation, and a Pages-oriented archive. Those are materially different artifacts, not merely alternate download formats.

After deployment, the documented acceptance path is concrete. Access `/UUID` or the configured custom management path, configure the login entry and credentials, and request `/sub` from a client. The subscription endpoint should return content appropriate to that client, such as YAML for Clash or JSON for sing-box. The README also records filename handling through `Content-Disposition`, including `.yaml`, `.json`, `.conf`, and `.txt` according to output type.

The repository does not state whether Pages uses a specific build command, whether a compatibility date must be selected, or how environment variables should be entered in either Cloudflare interface. Those details must be taken from the linked deployment material and the chosen build rather than inferred from the top-level filenames.

CFNext limits for source quality and client compatibility

CFNext's main limitation is that many features depend on remote data and client-specific behavior outside the project. Upstream node sources can be stale, unreachable, or incorrectly formatted. Although the panel can fetch as many as 50 custom sources and isolate a failure per source, successful parsing does not guarantee that a node can connect from every client network. Region labels may be inferred from names, and self-learned landing labels depend on measured routing outcomes.

Client compatibility is another boundary. CFNext attempts to identify Clash, sing-box, v2rayN, Karing, and Hiddify aliases, then falls back to Clash YAML for some unrecognized browser-like user agents. That fallback is useful, but it is not equivalent to native negotiation with every client. The README does not enumerate every accepted user agent or define the full behavior of clients that request the subscription endpoint outside those patterns.

Node probing is disabled by default with `probeAlive: false`. The default path publishes nodes in source order and lets clients choose. Enabling it through `PROBE_ALIVE=1` or the panel triggers live checks and reduced probe limits. The release notes explicitly say probe results are not cached because stale alive status could retain failed nodes. That choice favors freshness over repeated probe cost and means availability can vary between requests.

IPv6 adds another explicit tradeoff. The default policy does not deliver IPv6 nodes even when IPv6 is selected. Alternatives are backup-only or equal mixing, because reachability between a client network and Cloudflare varies. This is a sensible default for client-side selection, but it also means operators should not use the built-in default as evidence that IPv6 is generally unusable.

Static subscription generation versus CFNext routing

A static subscription script is the clearest alternative for simple deployments. Such a script can fetch one list, substitute fixed parameters, and return the result at a URL without maintaining a panel, KV state, rotation records, or server-side ProxyIP selection. This approach has fewer moving parts and makes its output easier to inspect. It is the better choice when the operator already has a curated node list and needs no regional filtering, per-client formats, quota suspension, or routing logic.

CFNext takes a different approach. It combines source ingestion, filtering, dynamic subscription formatting, optional probing, landing-point learning, ProxyIP matching, and KV-backed settings in one JavaScript deployment artifact. In exchange, the operator has more control over what clients receive. CFNext also applies subscription and panel rate limits, cache write budgets, quota policies, and output file naming, none of which are inherent to a static file.

Another possible alternative is an established proxy client that manages subscriptions locally. That approach keeps generation and filtering on the client, reducing reliance on a Cloudflare-hosted panel. CFNext instead centralizes administration for clients that consume an HTTP subscription, which is useful when the same configuration must be distributed across devices or maintained by an operator.

The choice should turn on operational need. If the requirement is merely to publish a stable list, CFNext adds significant configuration and state management. If the requirement includes country overrides, multiple client formats, ProxyIP routing, quota-driven stopping, and centralized changes, those added mechanisms define the reason to use CFNext.

Release history, maintenance evidence, and licensing

The repository is not archived, and its last push was on 2026-10-16. That is recent repository activity, but it does not by itself establish production reliability. The repository has no GitHub releases, even though the README contains extensive version history through V2.8.0. Consumers therefore cannot rely on GitHub's release page for downloadable assets or formal release notes and may need to compare source files and README entries directly.

Upgrade cost is not negligible. V2.7.0 changed routing behavior by removing fixed `/login` and unauthorized redirects, decoupled the password from the login path, added `login`, introduced a derived fallback UUID when `U` is absent, and added `MASK`. V2.8.0 changed ProxyIP from a single value to an ordered multi-source model, added `ADMIN` override behavior, and introduced strict quota mode. An operator carrying an older configuration must check whether its route, password assumptions, environment variables, and ProxyIP value still match the selected build.

The repository's license is unknown. The license metadata contains no recognized identifier, and the visible README excerpt does not state one. This blocks a confident assessment of redistribution, modification, or deployment rights. This is not legal advice, but it is a concrete adoption constraint. Organizations should obtain the license text from the repository owner before copying code into a product or distributing a modified build.

Editorial conclusion

CFNext fits operators who already understand Cloudflare deployment, KV, proxy routing, and subscription clients, and who accept responsibility for the security and compliance of their proxy setup. It is unsuitable for organizations requiring a documented license, a reproducible command-line installer, or clear operational ownership. Before adoption, inspect the selected JavaScript build, confirm the intended Cloudflare Workers or Pages configuration, and test the `/sub` output in the exact clients that will consume it.

Frequently asked questions

Official sources

1. Issues
2. PAICNI/CFNext on GitHub
3. README