Core Analysis¶

Project Positioning: CFnew integrates subscription conversion (multi-client config generation) and edge-based preference (latency testing, preferred IP/domain) into Cloudflare Workers/Pages, enabling an in-worker converter with live configuration changes and no external sub-converter dependency.

Technical Features¶

• Edge-based selection: Latency measurement and filtering run at the Worker close to users, reducing origin round-trips and enabling region-aware preselection.
• Built-in multi-client generation: Workers produce Clash, Surge, Sing-box, etc. formats directly, removing third-party converters and improving consistency and privacy control.
• KV + caching strategy: KV stores GUI configurations; a 30s short-window cache and cross-isolate version key c_ver ensure immediate effect after changes.
• Runtime overrides and API: URL path parameters allow per-node runtime overrides and a RESTful API manages preferred IPs for automation and sharing.

Practical Recommendations¶

1. Validate KV binding and compatibility date (2026-01-20) in a test environment before production usage to ensure Workers can read/write KV and generate target client formats.
2. Keep sensitive credentials in KV or env vars, avoid exposing them in public path parameters; use path overrides for temporary adjustments only.
3. Treat the edge preference as a preselection for connection quality, and combine it with ongoing monitoring; it should not replace long-term throughput or stability testing.

Caution¶

Important: Edge preference is based on CF IP probing and is not equivalent to real traffic bandwidth/stability testing. Also watch Cloudflare quotas and legal/compliance constraints.

Summary: CFnew’s main value is running subscription conversion and preference at the edge to enable immediate, multi-client compatible configs and reduced operational dependencies—while requiring attention to platform limits and scope of preference results.

Core Analysis¶

Key Question: What are the most error-prone points during deployment and operation, and how to avoid them?

Technical Analysis¶

• Mandatory platform settings:
• Set the Cloudflare Worker/Pages compatibility date to 2026-01-20 (the README repeatedly stresses this) to avoid runtime incompatibilities.

• Bind a KV namespace in Workers settings with the env var name C and verify read/write access after deployment.

• Runtime parameters and mutual exclusion:

• p (proxyip) and wk (region code) are mutually exclusive; mixing them can break preference logic. Priority is path params > KV/env vars > auto-detection.

• path parameters are convenient for per-node overrides but should not carry sensitive credentials in public links.

• Security and permissions:

• ae (enable API edits) is off by default; if enabled, restrict who can call the API. The preference API for add/clear should not be publicly unauthenticated.

Practical Recommendations¶

1. Perform end-to-end validation in a staging domain: verify compatibility date, KV binding, UUID path, and the parsing of generated formats for target clients.
2. Keep secrets in private KV or env vars and avoid embedding credentials in public paths; use path overrides only temporarily.
3. Highlight mutual exclusion rules in UI/docs (p vs wk) and add interactive prompts to reduce mistakes.
4. Restrict API management access and keep operation logs, and regularly backup KV configs and c_ver snapshots for rollback.

Caution¶

Important: Enabling ECH auto-enables “TLS-only” mode, which may affect expected behavior on port 80—verify client and environment compatibility before enabling.

Summary: A disciplined deployment checklist (compatibility date, KV binding, testing), credential isolation, and clear documentation of path param precedence are essential to avoid common mistakes.

Core Analysis¶

Architectural Assessment: Using Cloudflare Workers + KV enables moving subscription conversion and preference logic to the edge, leveraging proximity to users for latency probing and the operational simplicity of serverless deployment.

Technical Advantages¶

• Proximity-based probing: Edge latency measurements better reflect client experience and support region-aware preference.
• Immediate config propagation: KV with short-window caching and c_ver allows GUI changes to take effect without redeployments, improving ops speed.
• No external dependencies: In-worker generation of multi-client formats removes reliance on third-party sub-converters for consistency and privacy.

Inherent Limitations¶

• Platform quotas: Workers have CPU time, execution duration, and concurrency limits; KV has read/write per-second limits—heavy latency testing or high request volumes can hit quotas.
• KV sync and cold start issues: Cross-isolate consistency requires c_ver and short caching, but transient inconsistencies may occur.
• Not suitable for heavy traffic forwarding: Workers are not designed as high-throughput proxy relays.

Practical Recommendations¶

1. Combine in-memory caching with KV as fallback (the README mentions a 5-hour memory cache optimization) to reduce KV load.
2. Throttle latency measurements: Limit concurrent threads and cache recent results to avoid repeated probes.
3. Design fallback modes: Provide static subscription or read-only fallback when quotas are reached.

Caution¶

Important: Do not treat Workers as a high-throughput forwarding layer. Edge-based preference is a preselection tool and must be validated under real traffic for bandwidth and long-term stability.

Summary: Workers+KV is an appropriate architecture for immediate, visual edge subscription preference, but requires careful caching, throttling, and fallback design to mitigate platform constraints.

Core Analysis¶

Key Question: Can CFnew handle high concurrency or heavy traffic proxy forwarding? The answer is No—it’s designed as a control plane (subscription generation & preference) rather than a data plane for high-throughput forwarding.

Technical Analysis¶

• Unsuitable Scenarios:
• Sustained high-bandwidth forwarding (video streaming, large file transfers);

• Very high concurrency bursts with many subscription requests and simultaneous preference probes.

• Why it’s unsuitable:

• Workers impose CPU/time and concurrency limits; KV has read/write QPS limits—heavy preference probing or complex config generation can hit quotas.
• Preference probes are lightweight and do not substitute long-term bandwidth/stability testing.

Replacement and Degradation Strategies¶

1. Separate control plane and data plane: Keep CFnew for subscription conversion and preference, and route actual traffic to dedicated proxy/back-end clusters.
2. Cache preference results centrally: Periodically write edge preference results to a central backend and have Workers read cached results to reduce probing frequency.
3. Feature degradation under load: Disable auto-preference or extend preference intervals (e.g., from 15 minutes to longer), or serve static subscriptions when overloaded.
4. Use dedicated proxy clusters: For sustained high throughput, deploy dedicated VPSs or cloud load-balanced proxy clusters to carry the data plane.

Caution¶

Important: When designing alternatives, preserve subscription availability and secure management APIs; monitor Workers/KV metrics to trigger automated degradation.

Summary: CFnew is not intended for high-bandwidth/high-concurrency data-plane use. Under heavy traffic, limit it to control-plane duties and offload real traffic to dedicated backends.

Core Analysis¶

Key Issue: What practical benefits do ECH and ALPN provide, and what compatibility risks do they introduce?

Technical Analysis¶

• Benefits:
• ECH (Encrypted Client Hello): Hides SNI and improves domain privacy/fingerprint resistance. CFnew automatically fetches ECH configs via DoH and injects them on subscription refresh.

• ALPN (Application-Layer Protocol Negotiation): Specifying h3, h2, or http/1.1 can optimize transport negotiation and enable HTTP/3 features when supported by the backend.

• Compatibility & Risks:

• Client support variability: Not all clients or network middleboxes support ECH—older clients may fail the handshake.
• Affects fallback paths: Enabling ECH auto-enables “TLS-only” mode and may disable port 80 fallbacks; plan fallback strategies like qj=no.
• Network middleboxes: Transparent proxies or intervening devices can block or tamper with TLS handshakes, causing ECH/ALPN negotiation failures.

Practical Recommendations¶

1. Enable gradually and A/B test ECH/ALPN for a subset of users/nodes to monitor compatibility and success rates.
2. Provide toggles and fallbacks: Add GUI switches for ECH and document the “TLS-only” implications; ensure qj=no and other downgrade options are available.
3. Test target clients (Clash, Sing-box, Surge, etc.) for handshake and config parsing, especially ech-opts and query-server-name support.
4. Verify DoH provider stability before relying on automatic ECH fetches, since CFnew depends on DoH sources for ECH configs.

Caution¶

Important: Validate client and network compatibility before enabling ECH/ALPN; use fallback configs if incompatibilities arise.

Summary: ECH and ALPN can improve privacy and potentially performance, but must be enabled with careful compatibility testing and prepared rollback paths.