Подзапросы Worker

Почему поля origin пусты в исходном запросе, когда Worker выполняет подзапрос?

Когда запрос попадает в зону с Worker, исходная запись журнала HTTP-запроса отражает запрос конечного пользователя к Worker. Если этот Worker впоследствии выполняет fetch() запрос к вашему исходному серверу, Cloudflare записывает вторую запись журнала HTTP-запроса для этого подзапроса Worker.

Поскольку исходная запись журнала охватывает только запрос от клиента к Worker, OriginResponseStatus это 0 и OriginIP пусто в этой записи. Эти поля заполняются только во второй записи журнала, которая соответствует fetch-запросу от Worker к origin-серверу. Подробнее о том, что OriginResponseStatus=0 означает в разных контекстах, см. Ответы 504 с origin status 0 в Logpush.

Что означают эти две записи журнала

Запись журнала	Типичный `ClientRequestSource` значение	Что это означает	Поля origin-сервера
Исходный запрос	`eyeball`	Запрос конечного пользователя к Worker	`OriginResponseStatus` это `0`, `OriginIP` пусто
Подзапрос Worker	`edgeWorkerFetch`	Worker `fetch()` запрос к исходному серверу	Определяет момент обращения к origin-серверу

См. Поле ClientRequestSource для полного списка возможных ClientRequestSource значения.

Как связаны эти две записи

Каждая запись журнала имеет собственный RayID. Дочерний запрос Worker (subrequest) также включает ParentRayID, то есть RayID запроса, который его вызвал: его непосредственного родителя.

Поле	Исходный запрос	Подзапрос Worker
`RayID`	Уникальный ID запроса для запроса конечного пользователя	Уникальный ID запроса для подзапроса
`ParentRayID`	Очистить	`RayID` запроса, который его вызвал

Чтобы сопоставить эти две записи:

Найдите исходный запрос и запишите его RayID.
Найдите записи журнала, где ParentRayID означает, что RayID.
Просмотрите соответствующую запись журнала подзапроса для OriginIP, OriginResponseStatus, и другие поля источника.

Один запрос конечного пользователя может порождать несколько записей журнала для подзапросов Worker. Каждый подзапрос получает собственный RayID, и в каждой такой записи лога используется RayID в качестве своего ParentRayID.

ParentRayID является одноуровневым: он указывает на непосредственного родителя, а не на исходный запрос конечного пользователя. При использовании одного Worker это не имеет значения, поскольку родителем выступает сам запрос конечного пользователя. Когда Workers вызываются цепочкой (например, Worker A вызывает Worker B, который вызывает origin-сервер), запись подзапроса Worker B содержит RayID в качестве своего ParentRayID, а не конечного пользователя. Чтобы проследить всю цепочку до запроса конечного пользователя, переходите по каждому ParentRayID по одному уровню за раз.

Используя исходный запрос вместе с соответствующими записями подзапросов, вы можете восстановить полный путь запроса от клиента через Worker до origin-сервера.

Пример

# 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-to-origin для сопоставления. Например, Worker может вернуть ответ напрямую, не обращаясь к исходному серверу.