前言#
众所周知，Nat 机器由于大量用户公用一个 ipv4，很容因很容易被照顾，因此通常需要借助使用 cloudflare 使用。但是很多新手对如何套 cloudflare 一头雾水，即使是老手对于一些新的 cloudflare 特性也不是非常了解。还有一些朋友发现，其 nat 服务商的 ipv6 给的是 Hurricane Electric 的網絡地址，早年 cloudflare 為了避免濫用 “cf-he” 接入方式完全禁止了 HE 的 ipv6 網段，因此失去了下面要講的第一種方法的可能性，但這種情況下仍然可以成功利用 cloudflare 的，只是很多人不清楚，因此這裡關於 “套 cloudflare” 進行一下總結。
套 cloudflare 其實是一個很土的說法，其實就是利用 cloudflare 作為 CDN，當發起一個 http (s) 請求的時候，先由 cloudflare 接受，然後轉發到 nat 服務器。考慮到 cloudflare 作為網絡基礎設施，其被照顧的影響過於複雜因此很難直接照顧。
為什麼 nat 機器不好套 cloudflare 呢，是很多人習慣了直接用 vps 的公網 ipv4 接入 cloudflare，但是 nat 是沒有 ipv4 的，無法直接接入。還有一些服務商提供了 ipv6 only 的服務器，直接沒有 ipv4 地址，更需要特殊對待。針對不同的情況，有幾種變通策略。
使用 ipv6 接入#
最常見的，很多人第一反應就是使用 ipv6 接入，也就是添加 AAAA 解析。
常見的 nat 商家（比如 gullo/webhorizon/natvps.uk 等）都是提供 nat v4 + 獨立 ipv6 地址的，因此雖然無法直接使用共享 ipv4 的 80/443 端口進行接入，但是可以使用獨立 ipv6 接入，畢竟 ipv6 是獨享的所有端口皆可以使用。如下圖所示就是接好了。
這種接入方法是最容易想到，也是非常穩定的方案。但是有幾種情況不能使用這種方法：
- 如果商家的 ipv6 網絡是 Hurricane Electric，cf 禁止接入。比如 gullo 的部分地區（紐約等）
- 商家不提供 ipv6 地址，比如最近很火的 khanwebhost
使用 Origin Rules#
眾所周知，nat 服務器之所以被稱為 nat 服務器，是因為 ipv4 地址共享，每個人只能使用部分端口。那麼我們能不能使用這些端口進行接入呢。在半年前，也許答案是否定的，因為 Cloudflare 支持使用的非標端口很少，並且都是低位端口號，nat 服務商的端口號一般都在 10000 以上，因此不好使用 cf 支持的非標端口。但是今年 cloudflare 免費開放了他們的 Origin Rules，這允許我們使用任何端口接入到 cf 網絡。配置如下：
注意，vps 本地的 http 服務器（如 nginx）需要監聽對應的非標端口。
使用服務商域名 forwarding + cloudflare 接入#
一般而言，nat 機器服務商，都提供一種服務，就是域名 forwarding，簡單而言就是其宿主機器監聽公網 80/443 端口，然判斷收到請求的域名 (host/sni) 後 forward 到對應的 nat vps 實例的內網地址。
這種想法很好，但問題是很多他們用來監聽 80/443 端口的公網地址陣亡了。雖然如此，這並不影響我們使用 80/443 端口接入 cloudflare，我們仍然可以使用 cloudflare 添加 A 記錄到這些宿主機器的 ipv4 地址，然後在服務商面板上添加域名 forward 規則。
注意，vps 本地的 http 服務器（如 nginx）需要監聽對應的內網地址。
使用 Cloudflare 允許的非標準端口接入#
cloudflare 官方支持一系列非標準 web 端口進行接入，如果你的 ipv4 被照顧了，但是仍然想要接入，除了上面提到的兩種方法，還可以使用 Cloudflare 允許的非標準端口。具體可以用的端口如下：
那麼你可能會問了，這些端口我的 nat 機器服務商都沒有對我開放，怎麼辦。
nat 服務商除了提供域名映射以外，還提供端口映射，你可以把上面提到的 cf 支持的非標準端口轉發到內網 ip，然後使用 cf 添加 A 記錄解析，最後使用非標準端口訪問你的域名達到目的。只不過這種方法顯得比較雞肋，作為一種後備方案好了。
使用 cloudflare argo 接入#
最後的最後，有些情況下服務商並沒有提供公網 ipv4/ipv6，比如 pikapods 的容器服務，可以使用 cloudflare argo 接入。