之前使用 Gitbook 綁定自訂域名 read.yixiao.org 做了一篇文件，域名是托管在 Cloudflare 的，使用 CNAME 的方式接入 gitbook，後來不使用 gitbook，改變 CNAME 解析，解析到我自己的伺服器，同時開啟 Cloudflare 的 CDN，但是訪問 read.yixiao.org 依然跳轉到 gitbook，一開始我以為是因為 DNS 緩存，但是我等待了 24 個小時，依然如此。
與這個情況一樣。
嘗試解決#
我想了很多辦法，重置 DNS，刪除 Cloudflare 緩存，但都無法解決。
聯繫官方#
我嘗試聯繫 Cloudflare，但可惜我是 Free 套餐，無法發工單，所以我無法聯繫到 Cloudflare 官方。
之後在 GitHub 上聯繫了Gitbook 同時發郵件給 Gitbook，一天之後得到回覆和解決。
解決方案#
是 Gitbook 從 Cloudflare 中刪除了我的域名，之後就可以了。
以下為解釋原文#
Sorry for the trouble. I just wanted to give some additional context on this specific issue as it has been a recurring problem that we are aware of but sadly cannot be easily resolved.
TL;DR: To regain complete control of your custom hostname after it has been registered on app.gitbook.com, remove this custom hostname from our platform.
For the longer explanation:
We use Cloudflare to serve HTTPS traffic for all custom hostnames configured by our users.When a user configures a custom hostname, they point their DNS via CNAME to one of our domains (which, at the end of the chain points to Cloudflare). We then request Cloudflare (using their Cloudflare for SaaS product) to generate an SSL certificate for this hostname and serve the traffic properly.
When users move away from GitBook, they often don't remove their content from GitBook and only change the DNS on their side. We don't request to remove the hostname from Cloudflare for SaaS until the content is deleted from GitBook, as the goal is to avoid breaking links for URLs that are still pointing to GitBook.
We'd expect Cloudflare to always use the DNS setup of the domain as the primary factor for deciding where to route the traffic.
We don't know the rationale behind why Cloudflare routing continues internally routing the traffic to GitBook when the domain is no longer pointing to the GitBook hostname. But it is not us doing that intentionally.
機翻一下#
抱歉，添麻煩了。我只是想就這個特定問題提供一些額外的背景信息，因為這是一個我們知道但很遺憾無法輕易解決的反復出現的問題。
TL;DR：要在 app.gitbook.com 上註冊後重新獲得對自定義主機名的完全控制，請從我們的平台中刪除此自定義主機名。
對於更長的解釋：
我們使用 Cloudflare 為用戶配置的所有自定義主機名提供 HTTPS 流量。
當用戶配置自定義主機名時，他們通過 CNAME 將他們的 DNS 指向我們的域之一（在鏈的末端指向 Cloudflare）。然後我們請求 Cloudflare（使用他們的 Cloudflare for SaaS 產品）為此主機名生成 SSL 證書並正確地提供流量。
當用戶從 GitBook 離開時，他們通常不會從 GitBook 中刪除他們的內容，而只會更改他們這邊的 DNS。在內容從 GitBook 中刪除之前，我們不會請求從 Cloudflare for SaaS 中刪除主機名，因為目標是避免斷開仍指向 GitBook 的 URL 的鏈接。
我們希望 Cloudflare 始終使用域的 DNS 設置作為決定將流量路由到何處的主要因素。
我們不知道為什麼 Cloudflare 路由在域不再指向 GitBook 主機名時繼續在內部將流量路由到 GitBook 背後的基本原理。但這不是我們故意這樣做的。
總結#
這似乎是 Cloudflare 的問題，看一些帖子，官方計劃去年 12 月解決該問題。
simon-cf(I work at Cloudflare) are going to change the way this works so that the authoritative DNS dictates the behaviour, rather than the internal state where we currently require SSL for SaaS providers to manage off-boarding of their own customers. This work has been planned for some time and we're very pleased it will be done soon!
Current ETA for this is December.
simon-cf: 我們將改變這種工作方式，以便權威 DNS 決定行為，而不是我們目前要求 SaaS 提供商使用 SSL 來管理其自己客戶的離職的內部狀態。這項工作已經計劃了一段時間，我們很高興它將很快完成！
目前的預計到達時間為 12 月。
(機翻)
但是至少目前並沒有解決，希望盡快解決，這給我帶來了很大的困擾。。。。