Skip to main content

​
セットアップをテストする

以下のチェックはすべて GET リクエストを送信します。Profound の仕様は GET のみを対象としているため、HEAD を送信する curl -I ではなく curl -sD - -o /dev/null を使用してください。HEAD のレスポンスは、オリジンから返される場合もあれば、ボディを省略するハンドラーから返される場合もあり、ルーティングについては何もわかりません。
1

アシスタントのトラフィックが Profound に到達すること

x-concierge-request-id に UUID が含まれていること、および x-concierge-bot-kind: chatgpt-user を確認します。この 2 つが揃っていれば、CDN がリクエストを Profound にルーティングし、Profound がアシスタントを認識したことが証明されます。ただし、レンダリング済みのページが配信されたことの証明にはなりません。MISS と x-concierge-failopen: 1 の組み合わせは、Profound がオリジンのライブコンテンツを返したことを意味します。
2

公開済みのテストページが Profound から配信されること

セットアップ時に公開したページでは、x-concierge-cache: HIT とレンダリング済みの HTML も必須です。比較のためにボディを保存し、Profound が gzip エンコードで配信した場合に備えて curl に展開させます。
このリクエストが MISS の場合は、結果の読み方の説明に従って x-concierge-policy ヘッダーを確認してください。リクエストを繰り返しても MISS が HIT になることはありません。HIT になるのは、レンダリングを公開した場合のみです。
3

人間のトラフィックに影響がないこと

x-concierge-* ヘッダーがなく、ページの内容が以前と同じであることを確認します。レイテンシーとキャッシュヒット率もベースラインと比較してください。ルーティングが変わっていなくても、Worker や共有キャッシュポリシーの変更がそれらに影響する場合があります。
4

検索クローラーに影響がないこと

こちらも x-concierge-* ヘッダーがないことを確認します。このリクエストがルーティングされる場合は、よくある問題を参照してください。
5

除外対象のトラフィックが既存の動作を維持すること

ステージング環境で、GET 以外のメソッド、/api/users、/graphql、認証、管理、フレームワークのリソース、アセット(拡張子のないエンドポイントを含む)へのリクエストを送信します。データを変更する可能性のあるメソッドには無害なテスト用エンドポイントを使用し、Cookie や認可ヘッダーには機密ではないテスト値を使用してください。これらはすべて既存のルートのまま処理される必要があります。Vercel では、プレビューホストや代替ホストもテストしてください。
6

障害時の動作を安全にテストする

ステージング環境または分離された構成を使用し、元の設定を記録して、各テストの後に復元してください。
  • Cloudflare: 到達不能なアップストリーム、レスポンスヘッダーのタイムアウト、設定したフォールバックステータスのいずれかをテストします。x-concierge-cdn-failover: 1 が付いたオリジンのコンテンツが返されることを確認します。リダイレクト、404、429 はそのまま返され、すでにストリーミングが開始されたレスポンスは置き換えられません。
  • CloudFront: 設定した上限内でのプライマリの接続タイムアウトとレスポンスタイムアウト、および選択したステータス条件をテストします。設定した障害ではフォールバックオリジンが使用されますが、401 では使用されないことを確認します。キャッシュされていないリクエストを送信し、プライマリを復元した後も、キャッシュされたフォールバックレスポンスが TTL が切れるまで残ることを想定してください。
  • Vercel: CDN レベルのフェイルオーバーはありません。Profound の障害中やハードリジェクトの後は、アシスタントがエラーを受け取る場合があります。透過的なオリジンへのフォールバックは期待しないでください。
設定を復元した後、反映されるのを待ってから、ルーティングと公開済みページのチェックを繰り返してください。

​
ダッシュボードからセットアップの検証を実行する

Profound のダッシュボードでは、ルーティングのテストを代わりに実行できます。ネットワークの外部から、登録済みホスト上の URL に対して、サポート対象の 9 つのアシスタントの User-Agent 値をそれぞれ使ってリクエストを送信し、CDN がどのアシスタントを Profound にルーティングしたかを報告します。 これらのプローブには認証情報もループマーカーも含まれないため、CDN からは実際のアシスタントのトラフィックのように見えます。アシスタントがルーティングされたと見なされるのは、レスポンスに有効なリクエスト ID と一致するボットの種類が含まれている場合のみです。MISS、一時停止中のドメイン、リダイレクト、200 以外のステータスでも、ルーティングが確認できる場合があります。ページの状態は別途報告されます。テストする URL が公開ページの許可リストに含まれていることを確認してください。含まれていない場合、すべてのアシスタントが(正しく)ルーティングされていないと表示されます。
セットアップの検証は、ある時点における 1 つの URL のライブ観測です。各アシスタントに対して CDN のルールが実行されることは確認できますが、ドメインの所有権を検証するものではなく、公開済みのテストページを手動で確認する作業の代わりにもなりません。

​
レスポンスヘッダーのリファレンス

​
結果の読み方

​
エラーレスポンス

Profound がオリジンにフォールバックするのは、リクエストが認証され有効であった場合のみです。設定エラーはプロキシされずに拒否されます。Cloudflare の Worker は、設定された拒否ステータスをオリジンの配信によって隠します。CloudFront は 400 と 403 を隠しますが、401 は隠しません。Vercel には再試行がありません。拒否されるはずの場面でオリジンのページが表示された場合は、CDN の診断情報を確認してください。

​
よくある問題

User-Agent のパターンが、サポート対象のトークン一覧以外のものに一致しています。セットアップガイドのパターンおよびサポート対象のアシスタントと比較してください。Googlebot などの検索クローラーは、引き続きオリジンに到達する必要があります。
CloudFront は、オリジンリクエストポリシーで転送しない限り、オリジンリクエストのビューワー User-Agent を Amazon CloudFront に置き換えます。その場合、Profound には分類する情報がありません。CloudFront ガイドの、対象を絞ったカスタムオリジンリクエストポリシーを使用してください。AllViewer はビューワーの Host も転送し、Profound への接続を壊す可能性があるため、使用しないでください。User-Agent はキャッシュキーではなく、オリジンリクエストポリシーに追加してください。
適用されたルールの許可するアシスタントの一覧から、そのアシスタントが除外されています。レスポンスには、ルール ID とともに x-concierge-policy: off が表示されます。アシスタントを一覧に追加するか、一覧をクリアしてルールがドメインデフォルトを継承するようにしてください。
いずれかのキャッシュレイヤーが、アシスタントと人間のレスポンスを分離せずに、またはホスト、パス、クエリ文字列を分離せずに HTML を保存しています。CloudFront では、x-concierge-route をキャッシュキーに含め、Minimum TTL を 0 のままにし、ホストとクエリのバリアントを確認してください。Cloudflare では、Worker のアップストリーム呼び出しがキャッシュをバイパスしていることを確認してください。すべてのページが同じアップストリーム URL を使用するため、User-Agent をキーにするだけではページの識別を分離できません。Vercel では、プロジェクトの外部リライトのキャッシュ設定を確認してください。どのプロバイダーでも、置き換えの公開、公開の取り消し、一時停止を行った後にキャッシュエントリーがどうなるかを確認してください。CDN のエントリーは、Profound での変更後も残る可能性があります。
ループ防止が機能していません。ルールでは、x-concierge-request を含むリクエストをそのままオリジンに通過させる必要があります。Profound は自身のオリジンフェッチにこのヘッダーを付与し、このヘッダーを含む受信リクエストをすべて 400 で拒否するため、除外が壊れていても、ループではなく 1 回のリクエストの失敗で済みます。Vercel では、これは x-concierge-request に対する、値 ^1$(Profound が付与するマーカー)の missing 条件です。値を指定した missing 条件は、ヘッダーがその値に一致するリクエストのみを除外するため、他の正規表現を使用すると何の警告もなく除外が無効になります。
クエリ文字列はページ識別の一部です。CDN がオリジンリクエストの前にクエリ文字列を削除すると、/product?id=a と /product?id=b が /product にまとめられ、誤ったバリアントがレンダリングおよび配信されます。CloudFront では、ページの内容が変わるクエリ文字列(または「All」)をキャッシュポリシーに含めてください。オリジンリクエストポリシーでは、キーに含めずに追加のクエリ文字列を転送できるため、転送とキャッシュの識別は個別に確認してください。
レスポンスの x-concierge-policy と x-concierge-policy-source を確認してください。一致するルールがない場合は off となり、warm は公開済みのものが存在してもオリジンのライブコンテンツを配信します。適用されているルールを serve に設定してください。次に、この正確なパスとクエリの候補がレビューされ、公開されていることを確認してください。承認だけでは公開されず、リクエストを繰り返しても公開されません。pending として保留された候補は、誰かが承認、却下、または公開するまで pending のままです。ページが公開され、ポリシーが serve であるにもかかわらず MISS が表示される場合は、CDN のキャッシュとオリジンへの到達性を確認してください。
受信するアシスタントのトラフィックと Profound のオリジンフェッチの両方について、WAF のルール、ボットチャレンジ、デプロイ保護、オリジンの許可リストを確認してください。Profound は閲覧者の Cookie や認可ヘッダーを転送しないため、保護されたページやセッションに依存するページは、このセットアップの対象外とすべきです。ループマーカーは偽装可能であり、ファイアウォールや認証のバイパスに使用してはいけません。オリジン側で Profound のフェッチを識別する方法が必要な場合は、Profound サポートにお問い合わせください。

​
無効にする

CDN に手を加えずにレンダリングの配信を停止するには、Profound のダッシュボードでドメインを一時停止します。ルール、レンダリング、公開済みのものは保持されたまま、すべてのアシスタントのリクエストがオリジンに送られ、再開すると元に戻ります。一時停止は Profound では即座に反映されますが、CDN がすでにキャッシュしたレスポンスは有効期限が切れるまで残ります。リクエストは引き続き Profound に到達する必要があるため、一時停止は障害時の CDN レベルのフェイルオーバーの代わりにはなりません。 統合を削除するには、セットアップ前に記録しておいた CDN の設定を復元します。
  • Cloudflare: 追加した Worker ルートを削除するか、他の Worker ロジックを削除せずに以前のバインディングを復元します。
  • CloudFront: 以前のビューワーリクエストの関連付けとポリシーを復元します。No association は、以前に関連付けがなかった場合にのみ使用してください。
  • Vercel: vercel.json から追加したルートのみを削除し、その他のルーティングは維持したうえで再デプロイします。
ルーティングの変更は、設定またはデプロイメントが反映された後に有効になります。以前にキャッシュされたフォールバックレスポンスは、有効期限が切れるか、通常の無効化手順を行うまで残る場合があります。ロールバック後に、元のルーティングとコンテンツを確認してください。登録済みのドメイン、キー、公開済みのものは、削除するまで Profound に残ります。