Worker サブリクエスト

❮ FAQ に戻る

リクエストが Worker のあるゾーンに到達すると、最初の HTTP リクエストログは、エンドユーザーから Worker へのリクエストを表します。その Worker が後からオリジンへ fetch() すると、Cloudflare はその Worker サブリクエスト用に 2 つ目の HTTP リクエストログを書き込みます。

最初のログエントリはクライアントから Worker へのリクエストだけを対象にするため、そのエントリでは OriginResponseStatus は 0、OriginIP は空です。これらのフィールドは、Worker からオリジンへの fetch を表す 2 つ目のログエントリに入ります。状況ごとの OriginResponseStatus=0 の意味は、Logpush でオリジンステータス 0 の 504 レスポンス を参照してください。

ClientRequestSource のとりうる値の一覧は、ClientRequestSource フィールド を参照してください。

各ログエントリには独自の RayID があります。Worker サブリクエストには ParentRayID も含まれ、これはそのサブリクエストを起動したリクエスト（直近の親）の RayID です。

2 件のレコードを突き合わせるには:

1. 初期リクエストを見つけ、その RayID を控えます。
2. ParentRayID がその RayID と一致するログエントリを検索します。
3. 一致したサブリクエストのログで、OriginIP、OriginResponseStatus、その他のオリジンフィールドを確認します。

1 件のエンドユーザーリクエストから、複数の Worker サブリクエストログが生成されることがあります。各サブリクエストには独自の RayID が付き、それらのログエントリは起動元リクエストの RayID を ParentRayID として使います。

ParentRayID は 1 階層だけです。直近の親を指し、元のエンドユーザーリクエストを指すわけではありません。Worker が 1 つの構成では、親がエンドユーザーリクエストなので、この違いは問題になりません。Worker を連鎖させる場合（たとえば Worker A が Worker B を呼び、Worker B がオリジンを呼ぶ）、Worker B のサブリクエストログの ParentRayID は Worker A の RayID であり、エンドユーザーの RayID ではありません。エンドユーザーリクエストまでたどるには、ParentRayID を 1 階層ずつたどります。

初期リクエストと、対応するサブリクエストのエントリを合わせると、クライアントから Worker、オリジンまでのリクエスト経路を再構成できます。

# Initial request
ClientRequestSource: eyeball
RayID: 7b52f2c4f9f64c1a
ParentRayID:
OriginResponseStatus: 0

# Worker subrequest
ClientRequestSource: edgeWorkerFetch
RayID: 7b52f2c4f9f64c1b
ParentRayID: 7b52f2c4f9f64c1a
OriginResponseStatus: 200
OriginIP: 192.0.2.10

Worker がオリジンへ fetch() しない場合、突合する Worker からオリジンへのログエントリはありません。たとえば、Worker がオリジンに接続せず、直接レスポンスを返す場合があります。

Worker サブリクエストの調査を容易にするには、HTTP リクエストログに次のフィールドを含めます。

• RayID
• ParentRayID
• ClientRequestSource
• OriginIP
• OriginResponseStatus