Gitbook にカスタムドメイン read.yixiao.org をバインドして、ドキュメントを作成しました。ドメインは Cloudflare でホストされており、CNAME を使用して Gitbook に接続していました。しかし、Gitbook を使用しなくなり、CNAME の解析を変更して自分のサーバーに解析するようにしました。同時に Cloudflare の CDN を有効にしましたが、read.yixiao.org にアクセスすると依然として Gitbook にリダイレクトされます。最初は DNS キャッシュの問題だと思いましたが、24 時間待っても変わりませんでした。
この問題と同じです。
解決策を試す#
いくつかの方法を試しましたが、DNS をリセットしたり、Cloudflare のキャッシュを削除したりしても解決しませんでした。
公式に連絡する#
Cloudflare に連絡しようとしましたが、私は無料プランのユーザーなので、サポートチケットを送ることができませんでした。そのため、Cloudflare の公式に連絡することができませんでした。
その後、GitHub で Gitbook に連絡しました。1 日後に返信と解決策を得ました。
解決策#
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.
以下は機械翻訳です。#
問題が発生して申し訳ありません。この特定の問題について追加の文脈を提供したかっただけで、私たちはそれが再発する問題であることを認識していますが、残念ながら簡単に解決することはできません。
要するに、app.gitbook.com に登録されたカスタムホスト名の完全な制御を取り戻すには、このカスタムホスト名をプラットフォームから削除してください。
より詳しい説明については：
私たちは、ユーザーが構成したすべてのカスタムホスト名に対して HTTPS トラフィックを提供するために Cloudflare を使用しています。ユーザーがカスタムホスト名を構成すると、彼らは CNAME を介して DNS を私たちのドメインの 1 つにポイントします（このチェーンの最後には Cloudflare があります）。それから私たちは Cloudflare（彼らの Cloudflare for SaaS プロダクトを使用して）にこのホスト名のための SSL 証明書を生成し、トラフィックを適切に提供するように要求します。
ユーザーが GitBook から移動すると、彼らはしばしば GitBook からコンテンツを削除せずに DNS を変更するだけです。GitBook からコンテンツが削除されるまで、私たちは Cloudflare for SaaS からホスト名を削除するように要求しません。なぜなら、まだ GitBook を指している URL のリンクが壊れないようにすることが目的だからです。
私たちは、Cloudflare が常にドメインの DNS の設定を使用してトラフィックのルーティング先を決定するための主要な要素として期待しています。
ドメインがもはや GitBook のホスト名を指していない場合に、なぜ Cloudflare のルーティングが内部的に引き続きトラフィックを GitBook にルーティングし続けるのかについての理論はわかりません。ただし、私たちはそれを故意に行っているわけではありません。
結論#
これはおそらく Cloudflare の問題のようです。いくつかの投稿を見ると、公式は昨年 12 月にこの問題を解決する予定だったようです。
simon-cf（私は Cloudflare で働いています）：私たちはこれを解決するために方法を変更する予定です。権威ある DNS が動作を決定するために、現在は SSL for SaaS プロバイダーが独自の顧客のオフボーディングを管理するために SSL を要求している内部の状態ではなく。この作業は長い間計画されており、すぐに完了することを非常に喜んでいます！
現在の予定では、12 月です。
simon-cf：私たちはこれを解決するために方法を変更する予定です。権威ある DNS が動作を決定するために、現在は SSL for SaaS プロバイダーが独自の顧客のオフボーディングを管理するために SSL を要求している内部の状態ではなく。この作業は長い間計画されており、すぐに完了することを非常に喜んでいます！
現在の予定では、12 月です。
(機械翻訳)
しかし、現時点ではまだ解決されていないようです。早く解決してほしいです、これは私にとって大きな問題です。。。