Thanks / Reference
这份材料不是原创发明：方法来自社区，事实来自官方文档，结论由本机实测与交叉核验收口。 这一页说明素材从哪来、我们整理了哪些东西、以及哪些自己的推断被证伪了。
我们整理了哪些东西
| 内容 | 数量 | 位置 |
|---|---|---|
| Markdown 正稿 | 14 | drafts/ |
| 素材条目（正文可引用的编号） | 26 | notes/inbox.md（每条含结构化要点与核验批注） |
| 断言台账 | 37 | notes/facts.md（其中 3 条为已被我们自己证伪的留痕） |
| 本机实测证据 | 9 | notes/research/local-measurements.md |
| cloudflared 参数事实 | 46 | notes/research/cloudflared-knobs.md |
| 优选 / SaaS / 中国网络 官方边界 | 34 | notes/research/optip-boundaries.md |
| 原始素材归档文件 | 32 | reference/raw/（原文 + 清洗版 + 抓取状态台账） |
素材清单（逐条可追溯）
每一条素材都在正文里以 M-xxx 编号被引用；原文归档在 reference/raw/，清洗后的可读版本也在同目录。
| 编号 | 素材 | 来源 |
|---|---|---|
M-001 | linux.do #2736040「CF 优选 CANME 脚本」 | 链接 |
M-002 | idcflare.com《【建站提速】一文讲透 Cloudflare 优选加速，一个域名也能简单实现》 | 社区实践（教程帖，by node，2025-11-10，12.2k 浏览 / 1.2k 赞） |
M-003 | 用户要求的受众与范围（指令条目） | 用户明确要求，优先级高于我自己拟的骨架 |
M-004 | linux.do 两篇 MIYUSAMA 教程（含分地区解析的第三种架构） | 链接 |
M-005 | 《更直接更通透的理解 Cloudflare 的六大金刚》（MIYUSAMA） | 链接 |
M-006 | 双线加速：国内走第三方（阿里云 ESA）× 海外走 CF | 链接 |
M-007 | CF Tunnel 做内网穿透时的域名、备案与安全（linux.do #2853080） | 链接 |
M-008 | 两批新投递 | 链接 |
M-009 | Cloudflare Mesh / WARP 的"全局代理"副作用与送中风险（linux.do #2773401） | 链接 |
M-010 | 优选到底会不会封号（idcflare #48885） | 链接 |
M-011 | Tunnel 面板流量 vs 源站真实上传（idcflare #37288） | 链接 |
M-012 | 用 CF Tunnel 给服务器加网页 SSH 访问（idcflare #41595） | 链接 |
M-013 | 仅 IPv6 机加 WARP 后重启，CF Tunnel 断连（idcflare #41698） | 链接 |
M-014 | WARP 作入口的链式代理（linux.do 网络加速系列，by 66xiaoge） | linux.do 网络加速系列，by 66xiaoge |
M-015 | 节点搭建与"IP 质量"判据（linux.do #2823669） | 链接 |
M-016 | 免费域名 x10hosting 托管到 CF（含"双向解析"技巧，idcflare #5419） | 链接 |
M-017 | 国内服务器经 WARP 出口做境外访问（Warp 作 Docker 代理，linux.do #2853692） | 链接 |
M-018 | "服务器挂 CF 隧道后国内访问慢"的社区回答（linux.do #2865237） | 链接 |
M-019 | 源站 IP 泄露的六类成因与防护（idcflare #14307） | 链接 |
M-020 | idcflare #8519 | 链接 |
M-021 | 家庭服务器"远程访问"方案大对比（idcflare #16043） | 链接 |
M-022 | 常见线路与网络科普（idcflare #43467）★ 重点素材 | 链接 |
M-023 | IP 阻断 / DNS 污染 / SNI-Host 阻断（idcflare #38217）★ 机制底层 | 链接 |
M-024 | 机圈黑话 / 专有名词扫盲（idcflare #16977）★ 术语表素材 | 链接 |
M-025 | 《家庭服务器网络访问方案》后续楼层（idcflare #16043，96–108 楼） | 链接 |
M-026 | 【重要踩坑】Tunnel + 回源优选导致 Access 应用策略失效（idcflare #57598） | 链接 |
方法：三级证据标注
| 标注 | 含义 | 处理方式 |
|---|---|---|
[DOC] | 官方文档原文 | 直接引用；官方没有的说法会明确写出来（例如「QUIC 被限速必须切 http2」） |
[MEASURED] | 本机实测 | 附命令与原始输出；本机装了 Clash TUN 等会污染结论的环境，都会注明 |
[COMMUNITY] | 社区素材 | 标注「待核验」，并说明它与官方口径的差异在哪里 |
[INFERENCE] | 推断 | 只标注为推断，不写进结论 |
写下来的一条规矩：官方文档与社区说法冲突时，以官方为准，并把冲突本身写进稿子——因为读者最容易被这种冲突坑到。
更正记录（把被证伪的推断留痕）
| 编号 | 我最初的判断 | 实际结论 | 怎么发现的 |
|---|---|---|---|
| F-008 | 「tagzxia.com 本机解析异常，疑似 DNS 污染」 | ❌ 证伪：权威 NS 与 5 个独立来源一致解析；真实原因是 apex 是灰云记录、直指阿里云源站 | 用权威 NS 直查 + 换多个解析来源交叉验证 |
| F-019 | 社区说法「CF 免费版只分配几个固定 IP」 | ❌ 证伪：免费版同为 anycast 全网；实测同一域名经不同边缘 IP 可达 | 本机用 5 个不同网段边缘 IP 实测 |
| F-013 | 社区说法「大陆环境 QUIC 常被 QoS，要退回 --protocol http2」 | ❌ 官方无此建议：官方只给出两种可测 http2 的情形（UDP 建连失败、UDP 空闲超时致长连接掉线） | 逐字核对官方 run parameters 与排障文档 |
| F-061 | 社区实测「Go 的 http.ProxyFromEnvironment 不解析 socks5h://」 | ❌ 证伪：Go Transport.Proxy 文档明确支持 http/https/socks5/socks5h（socks5 视同 socks5h），默认端口 1080 | 直接读本机 Go 1.27.1 源码：transport.go 文档段 + socks5 分支 + schemePort |
留痕的意义：这些不是"写错了"，而是"核验发生过"的证据。 读者照着社区教程踩的坑，多半就埋在这三处。
主要感谢
- Cloudflare 官方文档：
developers.cloudflare.com（Tunnel / for SaaS / WARP / Trace / 错误码 / 定价）。官方文档把 Tunnel 拆成了 Zero Trust 与公开发布两条线，找参数时两条都要看。 - linux.do 与 idcflare 的社区作者：优选测速法、
dig +short的坑、SaaS 回源优选与 Access 策略的账号级冲突、以及「回源域名要阻止直连」这条正解，都来自这些帖子。 - 写长文的博主：把「优选」从一个黑话讲成一套可执行流程的那些文章，是本项目选题的起点。
- 本机实测环境：所有
[MEASURED]结论都来自本机与一台干净 VPS 的对照实验；凡是会被本地代理污染的实验，稿中都标了「结论不可用」。
复现方式
cd touch-cf-tutorial
sed -n '1,200p' notes/research/local-measurements.md # 逐条实测证据
TARGET=<你的橙云域名> SAMPLES=3 bash scripts/cf-optip-scan.sh # 自己重跑一遍优选
sed -n '1,120p' notes/facts.md # 断言台账与状态
python3 site/build.py # 重新生成本站