核心分析¶

项目定位：CFnew 的核心在于把订阅转换（多客户端格式生成）与边缘优选（延迟测试、优选 IP/域名）整合到 Cloudflare Workers/Pages 上，实现无需外部 sub-converter、配置即时生效的无服务器订阅引擎。

技术特点¶

• 边缘执行优选：在 Worker 端测延迟与筛选，靠近用户减少回源延迟，适合用于按地区/延迟预筛节点。
• 内置多客户端生成：Worker 内直接生成 Clash、Surge、Sing-box 等格式，避免依赖第三方转换工具，提高一致性与隐私可控性。
• KV + 缓存策略：通过 KV 存储图形化配置，结合 30s 短窗口缓存与跨 isolate 版本键 c_ver 实现立即生效的配置变更。
• 运行时覆盖与 API：支持 URL path 参数覆盖单节点变量，并提供 RESTful API 管理优选 IP，便于自动化和分享链接时的灵活控制。

实用建议¶

1. 先在测试环境完成 KV 绑定与兼容性日期设置（2026-01-20），确认 Worker 能正常读写 KV 并能生成目标客户端格式。
2. 将敏感凭据放在 KV 或环境变量，不在公开 path 中暴露；使用 path 参数做临时覆盖而非长期公开凭证。
3. 把优选定位为连接质量预筛，结合长期监控调整优选策略（追加/替换、地区筛选），不要把边缘优选当作长期带宽/稳定性替代测试。

注意事项¶

重要：边缘优选基于 CF IP/探测机制，不能完全替代真实流量下的带宽和稳定性评估；另外需遵守平台配额与合规要求。

总结：CFnew 的价值在于把订阅转换与优选逻辑带到边缘，实现即时生效与多客户端兼容，减轻运维和第三方依赖，但仍需注意 Workers 配额与优选结果的适用范围。

核心分析¶

核心问题：部署与日常操作中最容易出错的点在哪里？如何通过设置与流程避免？

技术分析¶

• 必须的平台设置：
• 将 Cloudflare Worker/Pages 的兼容性日期设置为 2026-01-20（README 多次强调），否则运行时可能出现不兼容或异常。

• 在 Workers 设置中绑定 KV 命名空间，环境变量名设为 C，并确保部署后能读写 KV。

• 运行时参数与互斥关系：

• p（proxyip）与 wk（地区代码）互斥，混用会导致优选逻辑异常；优先级是 path 参数 > KV/环境变量 > 自动检测。

• 使用 path 参数可方便地对单节点覆盖配置，但不要在公开链接中放置敏感凭证（如 SOCKS5 用户名/密码）。

• 安全与权限：

• ae（允许 API 管理）默认关闭，若开启应限制 API 的访问权限；优选 API（添加/清空）不应对公网无鉴权暴露。

实用建议¶

1. 部署前做一次端到端验证：在测试域名上验证兼容性日期、KV 绑定、UUID 路径和生成的几种客户端格式是否正确解析。
2. 把敏感值放到私有 KV 或 Worker 环境变量，不要通过公开路径分享真实凭证；利用 path 参数作为临时覆盖而非长期公开方案。
3. 在 GUI/文档中突出互斥规则（p 与 wk），并在界面上增加交互提示以减少误操作。
4. 限制 API 管理权限并记录操作日志，定期备份 KV 配置和 c_ver 版本快照以支持回滚。

注意事项¶

重要：开启 ECH 会自动启用“仅 TLS”模式，可能影响 80 端口的某些预期行为；在启用前确认客户端和环境兼容性。

总结：严谨的部署流程（兼容性日期、KV 绑定、测试）、凭证隔离和对 path 参数优先级的清晰文档是避免常见问题的关键。

核心分析¶

项目架构判断：选择 Cloudflare Workers + KV 是为把订阅转换与优选逻辑移到边缘，利用靠近用户的测延迟能力与无服务器部署带来的运维便利。

技术优势¶

• 靠近用户的探测能力：在边缘测延迟更接近真实客户端感受，可根据地区决策优选列表。
• 即时配置下发：KV 存储结合短窗口缓存和 c_ver 实现图形化修改后无需重部署即生效，提升运维效率。
• 无外部依赖：Worker 内直接生成多客户端格式，避免第三方 sub-converter 的可靠性与隐私问题。

隐含限制¶

• 平台配额：Workers 有 CPU 时间、执行时长与并发限制，KV 有每秒读写限制，长时间大量延迟测试或高并发订阅请求可能触及限额。
• KV 同步延迟与冷启动：跨 isolate 同步需靠 c_ver 与短缓存缓解，仍可能有短暂不一致。
• 不能做主流流量转发：Workers 不适合当作高带宽代理中继或持续流量转发层。

实用建议¶

1. 实现本地内存缓存 + KV 后备（README 提到 5 小时内存缓存的优化），尽量减少 KV 读写压力。
2. 把延迟测量节流化：限制并发线程数（内置 1–50）并对频繁请求实施短期缓存。
3. 设计降级路径：当触发配额或 KV 超限时，提供简单的静态订阅或降级到只读模式。

注意事项¶

重要：不要把 Workers 当作高吞吐转发层；优选结果仅作为预筛，长期稳定性和带宽仍需在真实流量下验证。

总结：Workers+KV 是实现即时、可视化边缘订阅优选的合理选择，但必须围绕缓存、节流和降级策略来规避平台配额影响。

核心分析¶

问题核心：CFnew 是否能承担高并发或大流量的代理转发任务？结论是——不适合。它应作为控制面（订阅生成、优选）而非数据面（高带宽代理中继）。

技术分析¶

• 不适用的场景：
• 需要持续大带宽转发的主代理中继或实时视频/大文件传输场景；

• 极高并发的短时峰值（大量订阅请求 + 实时优选同时发生）。

• 为何不适合：

• Workers 有 CPU/执行时长与并发限制，KV 存取有 QPS 限制；大量优选或复杂配置生成会触发限额或延迟。
• 优选基于轻量探测，不能替代长期带宽/稳定性测试。

替代与降级策略¶

1. 分离控制面与数据面：保留 CFnew 做订阅转换与优选（控制面），把实际流量导向专用代理或中心化转发节点（数据面）。
2. 缓存优选结果到中心服务：将边缘优选结果周期性写到中心化后端，由后端批量下发或由 Worker 读取缓存以减少探测频率。
3. 功能降级：在高负载时关闭自动优选或延长优选间隔（从每15分钟改为更长），或仅提供静态订阅以减少计算。
4. 使用专用代理集群：如需持续高带宽，使用专用 VPS/专线或云负载均衡的后端代理集群来承载流量。

注意事项¶

重要：在设计替代方案时，确保订阅的可用性与安全性（别把管理 API 公开），并监控 Workers/KV 指标以触发自动降级。

总结：CFnew 非为高带宽/高并发数据面设计。遇到大流量应把它的职责限定为控制面，结合中心化或专用后端来处理真实流量。

核心分析¶

问题核心：启用 ECH 与 ALPN 对终端体验有什么实际提升？同时会带来哪些兼容性风险？

技术分析¶

• 可获得的好处：
• ECH（Encrypted Client Hello）：隐藏 SNI，提升域名隐私与抗指纹能力；CFnew 支持自动从 DoH 获取 ECH 配置并在订阅刷新时注入。

• ALPN（应用层协议协商）：可显式声明 h3、h2、http/1.1 等，配合后端支持可提升连接效率或启用 HTTP/3 特性。

• 兼容性与风险：

• 客户端支持差异：并非所有客户端或中间网络都支持 ECH；部分老旧客户端会因握手不兼容而失败。
• 影响回退路径：启用 ECH 会自动启用“仅 TLS”模式，可能使基于 80 端口的回退不可用，需要确认回退策略（如 qj=no）。
• 网络中间件限制：某些透明代理或中间件可能阻断或篡改 TLS 握手，导致 ECH/特定 ALPN 协商失败。

实用建议¶

1. 逐步启用并 A/B 测试：对少量用户/节点开启 ECH/自定义 ALPN，观察兼容性与连接成功率变化。
2. 提供开关与回退：在 GUI 中为 ECH 提供开/关，并在订阅中标注“仅 TLS”模式说明；准备 qj=no 等降级策略以避免不可达情况。
3. 测试主要客户端：针对目标客户端（Clash、Sing-box、Surge 等）做握手与解析测试，确保 ech-opts、query-server-name 配置能被客户端正确识别。
4. 在启用前验证 DoH 源稳定性：CFnew 的 ECH 自动获取依赖 DoH，确认 DoH 提供方稳定以避免时常失效。

注意事项¶

重要：启用 ECH 与自定义 ALPN 前请先验证客户端与网络兼容性；出现不兼容时优先使用回退配置以保障可用性。

总结：ECH/ALPN 能带来隐私和性能优化，但必须以兼容性验证与回退机制为前提。