← Cloudflare Workers / workers / configuration

Флаги совместимости

Флаги совместимости включают отдельные функции. Они полезны, если вы хотите помочь команде Workers протестировать готовящиеся изменения, которые пока не включены по умолчанию, или если нужно отложить изменение, от которого зависит ваш код, но при этом применить остальные изменения совместимости.

У флагов совместимости часто есть дата, начиная с которой они включаются по умолчанию, и поэтому, указав compatibility_date для вашего Worker, вы можете быстро включить все эти флаги совместимости вплоть до этой даты включительно.

Вы можете указать список compatibility_flags, которые включают или отключают определённые изменения.

Флаги совместимости можно задать в конфигурационный файл Wrangler.

В этом примере включается флаг formdata_parser_supports_files, который описан ниже. Начиная с указанной даты, 2021-09-14, этот флаг ещё не был включён по умолчанию, но при указании его в compatibility_flags, мы всё равно можем это включить. compatibility_flags также можно использовать для отключения изменений, которые ранее стали поведением по умолчанию.

{
	// Opt into backwards-incompatible changes through September 14, 2021.
	"compatibility_date": "2021-09-14",
	// Also opt into an upcoming fix to the FormData API.
	"compatibility_flags": [
		"formdata_parser_supports_files"
	]
}

compatibility_date = "2021-09-14"
compatibility_flags = [ "formdata_parser_supports_files" ]

Флаги совместимости можно обновить в настройках Workers на Панель управления Cloudflare ↗.

Флаги совместимости можно задать при загрузке Worker с помощью Workers Script API или Workers Versions API в теле запроса metadata поле.

A растущее подмножество API Node.js доступны напрямую как Runtime API, без необходимости добавлять полифилы в свой код.

Для дат совместимости 2026-08-04 или более поздней версии проекты Workers и Pages включают оба nodejs_compat и nodejs_compat_v2 по умолчанию. Встроенные API среды выполнения и полифиллы доступны без дополнительной настройки. Для этих дат совместимости данные флаги не используются. Существующим проектам не нужно удалять их при обновлении даты совместимости.

Если ваша дата совместимости раньше 2026-08-04, добавьте nodejs_compat флаг совместимости в ваш конфигурационный файл Wrangler чтобы включить:

{
	"compatibility_flags": [
		"nodejs_compat"
	]
}

compatibility_flags = [ "nodejs_compat" ]

Чтобы отключить Совместимость с Node.js полностью при дате совместимости 2026-08-04 или более поздней версии удалите положительные флаги, если они есть. Затем добавьте оба no_nodejs_compat и no_nodejs_compat_v2. Примеры настройки см. в Флаг совместимости с Node.js.

Для дат совместимости 2026-08-04 или более поздней версии Workers включает оба nodejs_compat и nodejs_compat_v2 по умолчанию. Для этих дат совместимости данные флаги не используются, так как дата совместимости обеспечивает такое же поведение. Wrangler, Miniflare, плагин Cloudflare для Vite и плагин Workers для Vitest игнорируют эти избыточные флаги при запуске среды выполнения. Существующим проектам не нужно удалять их при обновлении даты совместимости. В новых конфигурациях их указывать не следует.

Чтобы полностью отключить совместимость с Node.js для даты совместимости 2026-08-04 или более поздней версии удалите nodejs_compat и nodejs_compat_v2 если он присутствует. Затем добавьте оба следующих флага:

{
	"compatibility_flags": [
		"no_nodejs_compat",
		"no_nodejs_compat_v2"
	]
}

compatibility_flags = [ "no_nodejs_compat", "no_nodejs_compat_v2" ]

Node.js AsyncLocalStorage API особенно полезен для Workers. Чтобы включить только AsyncLocalStorage API используйте nodejs_als флаг совместимости.

{
	"compatibility_flags": [
		"nodejs_als"
	]
}

compatibility_flags = [ "nodejs_als" ]

Новейшие флаги указаны первыми.

Когда remove_nodejs_compat_eol_v24 включен, удаляются API, чей жизненный цикл завершился в Node.js 24.x.

Этот флаг автоматически включается, когда remove_nodejs_compat_eol флаг включён после 2028-04-30.

Когда remove_nodejs_compat_eol_v22 включен, удаляются API, чей жизненный цикл завершился в Node.js 22.x.

Этот флаг автоматически включается, когда remove_nodejs_compat_eol флаг включён после 2027-04-30.

Если этот параметр включен, передача неподдерживаемых параметров TLS (например, checkServerIdentity) в tls.connect() или new TLSSocket() выбрасывает ERR_OPTION_NOT_IMPLEMENTED вместо того чтобы молча их игнорировать

Если python_process_pth_files флаг установлен, Python Workers обрабатывают .pth файлы в python_modules/ каталог при запуске, вызвав site.addsitedir() ↗ на нём. Это позволяет пакетам расширять sys.path декларативно, например, чтобы добавить подкаталоги или зарегистрировать хуки импорта. Без этого флага .pth файлы в python_modules/ игнорируются.

Этот флаг также выносит менеджеры контекста энтропии верхнего уровня, необходимые некоторым пакетам, из среды выполнения в workers-py ↗.

Необходимо использовать workers-py версия 1.1.3 или более поздней версии, когда установлен этот флаг.

Когда diagnostics_channel_has_subscribers_getter включен, Channel.hasSubscribers и TracingChannel.hasSubscribers от node:diagnostics_channel становятся доступными только для чтения свойствами геттера, которые сразу вычисляются в булево значение, что соответствует поведению Node.js.

Ранее, hasSubscribers был зарегистрирован как метод, что требовало от пользователей вызывать ch.hasSubscribers() со скобками. При включенном этом флаге ch.hasSubscribers возвращает boolean без вызова функции, что соответствует документация Node.js ↗.

Для этого флага требуется nodejs_compat быть включённым.

Если этот параметр включен и Workflow шаг выбрасывает NonRetryableError, ошибка message и name свойства сохраняются в выброшенном исключении вместо замены на общую строку завершения.

Ранее выброс NonRetryableError с пользовательским сообщением приведет к тому, что исходное сообщение об ошибке будет потеряно и заменено на "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled":

import { WorkflowEntrypoint, NonRetryableError } from "cloudflare:workers";

export class MyWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    await step.do("my-step", async () => {
      throw new NonRetryableError("custom error message");
      // Without this flag: error.message === "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled"
      // With this flag: error.message === "custom error message"
    });
  }
}

С workflows_preserve_non_retryable_error_message флаг включён, исходные сообщение и название ошибки сохраняются, что упрощает отладку и обработку конкретных случаев ошибок в коде вашего Workflow.

Когда enhanced_error_serialization включен, ошибки, сериализованные с помощью structuredClone() или сериализация V8 поддерживают больше типов ошибок и включают собственные свойства объекта ошибки.

Обратите внимание, что при включении этой опции десериализация ошибок по умолчанию не сохраняет исходную трассировку стека.

Ранее только базовые Error типы сериализовались, а собственные свойства, добавленные к объектам ошибок, терялись при сериализации.

Когда containers_pid_namespace задан, контейнеры будут использовать изолированное пространство имён PID. ENTRYPOINT вашего контейнера будет иметь PID 1.

Если этот параметр не задан, контейнер использует общее пространство имён PID с виртуальной машиной (VM), в которой он размещён. ENTRYPOINT вашего контейнера будет не имеет PID 1, и другие процессы, выполняющиеся на виртуальной машине (не входящие в ваш контейнер), будут видны.

Когда encoder_stream_spec_compliant_backpressure включен, TextEncoderStream и TextDecoderStream используйте high water mark на стороне чтения, равный 0, как указано в WHATWG Encoding Standard ↗.

При high water mark, равном 0, readable-сторона изначально работает с применением backpressure, поэтому записи корректно блокируются, пока reader не выполнит pull. Раньше high water mark по умолчанию был равен 1, что приводило к pull() чтобы сработать при запуске и снять backpressure ещё до первой записи.

Когда writable_stream_spec_compliant_writer включен, несколько WritableStream устранены проблемы соответствия спецификации, связанные с поведением блокировки и снятия блокировки в writer, чтобы соответствовать WHATWG Streams Standard ↗.

Когда enable_global_performance_classes включен, в глобальной области видимости доступны следующие классы: PerformanceEntry, PerformanceMark, PerformanceMeasure, PerformanceResourceTiming, PerformanceObserver, а также PerformanceObserverEntryList.

Эти классы также неявно включаются enable_nodejs_perf_hooks_module флаг.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

enable_nodejs_child_process_module флаг включает node:child_process заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:child_process API.

enable_nodejs_perf_hooks_module флаг включает node:perf_hooks модуль в Workers. Этот флаг также неявно включает глобальные классы Performance (PerformanceEntry, PerformanceMark, PerformanceMeasure, PerformanceResourceTiming, PerformanceObserver, а также PerformanceObserverEntryList).

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:perf_hooks API.

enable_nodejs_readline_module флаг включает node:readline заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:readline API.

enable_nodejs_repl_module флаг включает node:repl заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:repl API.

enable_nodejs_tty_module флаг включает node:tty заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:tty API.

enable_nodejs_v8_module флаг включает node:v8 заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:v8 API.

enable_nodejs_worker_threads_module флаг включает node:worker_threads заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-03-17 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:worker_threads API.

Этот флаг управляет значением по умолчанию для binaryType свойство у WebSocket, который, в свою очередь, определяет, как двоичные кадры доставляются в message событие. При включённом флаге binaryType по умолчанию равно "blob" и бинарные фреймы поступают в виде Blob ↗ объекты, соответствующие Спецификация WebSocket ↗ и стандартным поведением браузера. Без этого флага binaryType по умолчанию равно "arraybuffer" и бинарные фреймы поступают в виде ArrayBuffer ↗, соответствуя историческому поведению runtime.

binaryType свойство само по себе доступно в каждом WebSocket независимо от флага. Присвоение значения переопределяет значение по умолчанию для конкретного WebSocket:

const resp = await fetch("https://example.com", {
  headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery before calling accept().
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
  // event.data is an ArrayBuffer for binary frames.
});

Если вы ещё не готовы к переходу и хотите оставить ArrayBuffer по умолчанию для каждого WebSocket в вашем Worker, добавьте no_websocket_standard_binary_type флаг в ваш конфигурационный файл Wrangler.

Этот флаг не влияет на переходящий в спящий режим (hibernatable) WebSocket webSocketMessage обработчик, который всегда получает бинарные данные в виде ArrayBuffer.

Когда queue_expose_error_codes включен, Queue операции будут включать подробную информацию об ошибках, в том числе коды ошибок и их причины, что упрощает программную обработку и диагностику ошибок очереди.

Когда сервер отправляет WebSocket-фрейм Close, среда выполнения Workers теперь автоматически отправляет ответный фрейм Close и переводит readyState к CLOSED перед вызовом события close событие. Это соответствует Спецификация WebSocket ↗ и поведением браузера.

Ранее получение инициированного сервером кадра Close оставляло WebSocket в состоянии CLOSING и требовалось, чтобы приложение вызывало close() сам по себе. Когда этот флаг активен, вам больше не нужно вызывать close() в вашем close обработчик события. Среда выполнения автоматически обрабатывает процедуру закрытия соединения.

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
  // readyState is already CLOSED — no need to call server.close().
  console.log(server.readyState); // WebSocket.CLOSED
  console.log(event.code); // 1000
  console.log(event.wasClean); // true
}, { once: true });

Если вы всё же вызываете close() внутри обработчика, вызов молча игнорируется. Это значит, что существующий код, вручную отвечающий на Close фреймы, не сломается при обновлении даты совместимости.

Автоматическое закрытие соединения может мешать проксированию WebSocket. Когда Worker проксирует соединение между клиентом и бэкендом, прежнее поведение позволяло Worker увидеть фрейм Close от бэкенда без разрыва соединения средой выполнения, что давало Worker время скоординировать корректное закрытие на стороне клиента. Чтобы поддержать этот сценарий, accept() метод теперь принимает параметр allowHalfOpen. Вызовите ws.accept({ allowHalfOpen: true }) чтобы восстановить прежнее поведение half-open независимо от флага совместимости.

const [client, server] = Object.values(new WebSocketPair());

// Opt into half-open mode for proxying
server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
  // With allowHalfOpen true, readyState is still CLOSING here,
  // giving you time to coordinate the close on the other side.
  console.log(server.readyState); // WebSocket.CLOSING

  // Manually close when ready.
  server.close(1000, "done");
}, { once: true });

Обратите внимание, что не существует соответствующего параметра для WebSocket конструктор. WebSocket, созданные с помощью new WebSocket всегда будет автоматически отвечать на закрытие соединения после вступления этого флага в силу. WebSocket, созданные таким образом, автоматически «принимаются», поэтому передать этот параметр в accept(). Если вы создаёте WebSocket с помощью new WebSocket, но вам нужно полуоткрытое поведение, вам придётся перейти на использование fetch() взамен.

// This does not allow half-open:
let ws = new WebSocket("wss://example.com");

// But you can do this instead:
let resp = await fetch("https://example.com", {
  headers: { "Upgrade": "websocket" }
});
if (!resp.webSocket) {
  throw new Error("WebSocket handshake not accepted");
}
let ws = resp.webSocket;
ws.accept({ allowHalfOpen: true });

Дополнительные сведения см. в Документация по WebSocket API.

Когда text_decoder_cjk_decoder включен, выделенный CJK TextDecoder реализация используется для переопределения кодировок CJK и обработки старшего байта Big5 вместо устаревшего пути кода, основанного только на ICU. Это повышает соответствие спецификации при декодировании текста CJK.

Когда unhandled_rejection_after_microtask_checkpoint включен, unhandledrejection обработка события откладывается до завершения контрольной точки микрозадач. Это предотвращает ложные срабатывания в многотактовых цепочках промисов, где обработчик отклонения добавляется в более позднюю микрозадачу.

Ранее обработка unhandled rejection могла срабатывать преждевременно, до завершения всех microtasks в текущем checkpoint, что приводило к ложным unhandledrejection события для промисов, которые были фактически обработаны.

Когда websocket_close_reason_byte_limit включен, WebSocket.close() выбрасывает SyntaxError DOMException если reason строка превышает 123 байта при кодировании в UTF-8, как того требует спецификация WebSocket от WHATWG ↗ и RFC 6455, раздел 5.5 ↗.

Workers ранее разрешал произвольно длинные причины закрытия соединения без проверки.

С delete_all_deletes_alarm флаг, вызов deleteAll() для хранилища Durable Object удалит любой активный alarm в дополнение ко всем сохранённым данным. Ранее deleteAll() удалял только данные, сохранённые пользователем, а для alarms требовался отдельный deleteAlarm() вызов для удаления. Это изменение применяется как к Durable Objects на основе KV, так и к Durable Objects на основе SQLite.

Когда text_decoder_replace_surrogates включен, UTF-16le TextDecoder заменит одиночные суррогаты на U+FFFD (символ замены Unicode), как того требует Encoding Standard ↗. Раньше одиночные суррогатные пары передавались без изменений, что приводило к некорректно сформированным строкам.

Когда fetch_iterable_type_support включен, синхронные и асинхронные итерируемые объекты можно передавать в качестве тела fetch() Request или Response и будет корректно проходить итерацию.

Ранее синхронные итерируемые объекты, такие как Arrays, принимались, но приводились к строке (например, [1, 2, 3] станет "1,2,3"), а асинхронные итерируемые объекты будут восприниматься как обычные объекты и вообще не будут проходить итерацию. При включении этого флага итерируемые объекты корректно обрабатываются как потоковое содержимое тела запроса.

Обратите внимание, что теперь массивы обрабатываются как итерируемые объекты, а не преобразуются в строку. Это критическое изменение для кода, который полагался на прежнее поведение.

Когда enable_nodejs_global_timers включен, setTimeout, setInterval, clearTimeout, а также clearInterval возвращает совместимые с Node.js Timeout объекты с такими методами, как refresh(), ref(), unref(), а также hasRef(), соответствуя поведению node:timers.

Для этого флага требуется nodejs_compat быть включённым и автоматически включается для Workers с датой совместимости 2026-02-10 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями об API таймеров.

enable_nodejs_dgram_module флаг включает node:dgram заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-01-29 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:dgram API.

enable_nodejs_inspector_module флаг включает node:inspector заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-01-29 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:inspector API.

enable_nodejs_sqlite_module флаг включает node:sqlite заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-01-29 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:sqlite API.

enable_nodejs_stream_wrap_module флаг включает node:_stream_wrap заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2026-01-29 или более поздней, когда nodejs_compat включён.

Когда require_returns_default_export включен, require() вернёт экспорт по умолчанию модуля, если он существует. Если экспорта по умолчанию нет, вместо него возвращается изменяемая копия объекта пространства имён модуля.

Это соответствует поведению, которое Node.js использует для require(esm), где при наличии возвращается экспорт по умолчанию. Этот флаг полезен для фреймворков вроде Next.js, которые рассчитывают на возможность изменять экспортируемые модули.

Ранее, require() всегда возвращал объект пространства имен модуля (объект вида {default: module.exports}).

Изменяет семантику владения RPC-заглушками, встроенными в параметры RPC-вызова, устраняя проблемы совместимости с Cap'n Web ↗.

Если система Workers RPC впервые появился, право собственности на RPC заглушки, встроенные в параметры или возвращаемое значение другого вызова, переходило к получателю. То есть исходная заглушка неявно уничтожалась, а получателю отправлялась её копия.

Это плохо сочетается с другим правилом: в получателе вызова любые стабы, переданные в параметрах вызова, автоматически освобождаются по завершении вызова. Из сочетания этих двух правил следует, что при проксировании вызова, то есть когда реализация RPC просто выполняет еще один RPC вызов с теми же параметрами, стабы в параметрах освобождаются дважды. Хуже того, если конечный получатель стаба хочет сохранить копию после завершения вызова, это может не сработать, поскольку копия стаба на уровне прокси всё равно освобождается, разрывая соединение.

По этой причине чистая JS реализация Cap'n Web стала считать, что стабы в параметрах НЕ передают владение, а просто дублируются. Этот флаг совместимости приводит встроенный RPC в Workers Runtime в соответствие с поведением Cap'n Web.

Один из распространенных случаев, которые это исправляет, это клиенты, подписывающиеся на обратные вызовы от Durable Object через Cap'n Web. В этом случае клиентское приложение передает функцию обратного вызова через WebSocket Cap'n Web на Worker без состояния, который в свою очередь пересылает stub через Workers RPC в Durable Object. Durable Object сохраняет dup() заглушки (stub), чтобы впоследствии вызвать её и уведомить клиента о событиях. К сожалению, до появления этого флага это не работало: как только сама функция subscribe завершала выполнение, заглушка Cap'n Web в stateless worker уничтожалась (поскольку она была параметром вызова, который завершился, и не была dup(), то есть не был повторно продублирован в контексте worker без сохранения состояния). Поэтому когда Durable Object позже попытался вызвать callback подписки, он получил ошибку «Error: RPC stub used after being disposed», хотя перед этим он аккуратно dup(), то есть продублировал заглушку в конце.

Когда fetch_iterable_type_support_override_adjustment включен, объекты, переданные в качестве тела fetch() Request или Response которые поддерживают синхронную итерацию, но также имеют собственный toString или Symbol.toPrimitive метод не будет обрабатывать их как итерируемые объекты. Вместо этого они будут обрабатываться как объекты, приведённые к строке, что соответствует прежнему поведению для таких объектов.

Этот флаг уточняет поведение, введённое fetch_iterable_type_support флаг и автоматически включается, когда fetch_iterable_type_support включается начиная с 2026-01-15.

Когда strip_bom_in_read_all_text включен, readAllText() метод для потоков удаляет начальную метку порядка байтов UTF-8 (BOM), если она присутствует, в соответствии с ожидаемым поведением согласно стандартам веб-платформы.

Ранее BOM включался в возвращаемую строку, что могло приводить к неожиданному поведению при разборе текстового содержимого.

enable_nodejs_cluster_module флаг включает node:cluster заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-12-04 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:cluster API.

enable_nodejs_domain_module флаг включает node:domain заглушка модуля в Workers. Обратите внимание, что node:domain считается устаревшим в самом Node.js.

Этот флаг автоматически включается для Workers с датой совместимости 2025-12-04 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:domain API.

enable_nodejs_punycode_module флаг включает node:punycode модуль в Workers. Обратите внимание, что node:punycode считается устаревшим в самом Node.js.

Этот флаг автоматически включается для Workers с датой совместимости 2025-12-04 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:punycode API.

enable_nodejs_trace_events_module флаг включает node:trace_events заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-12-04 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:trace_events API.

enable_nodejs_wasi_module флаг включает node:wasi заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-12-04 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:wasi API.

Когда enable_fast_jsg_struct включен, внутренние структурные типы, используемые API среды выполнения Workers, создаются по более эффективной схеме, сокращающей время создания объектов.

Однако необязательные поля будут явно установлены в значение undefined а не полностью опускается из объекта, что является заметным изменением поведения. Код, проверяющий наличие свойства с помощью "key" in obj или Object.hasOwn(obj, "key") может вести себя иначе, поскольку необязательные поля, которых раньше не было, теперь будут присутствовать со значением undefined.

Чтобы проверить значение, используйте предпочтительно obj.key !== undefined через "key" in obj.

Этот флаг включает ctx.exports API, который содержит автоматически настроенные loopback bindings для экспортов верхнего уровня вашего Worker. Это позволяет не настраивать явные привязки для вашего WorkerEntrypoints и пространства имен Durable Object, определенные в том же Worker.

Этот флаг включит Workers Tracing по умолчанию, если в конфигурационном файле Wrangler указано следующее:

{
	"observability": {
		"enabled": true
	}
}

Также можно явно включить автоматическую трассировку без этого флага и с более старыми датами совместимости, задав следующее:

{
	"observability": {
		"traces": {
			"enabled": true
		}
	}
}

enable_nodejs_vm_module флаг включает node:vm заглушка модуля в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-10-01 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:vm API.

enable_nodejs_console_module флаг включает node:console модуль в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-21 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:console API.

Когда enable_validate_workflow_entrypoint включен, выполняются дополнительные проверки, гарантирующие, что Workflows определены и используются правильно. Это помогает выявлять ошибки конфигурации при загрузке, а не во время выполнения.

enable_nodejs_fs_module флаг включает node:fs модуль в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-15 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:fs API.

enable_nodejs_os_module флаг включает node:os модуль в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-15 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:os API.

Если включено после 2025-09-15, enable_nodejs_process_v2 флаг вместе с nodejs_compat флаг совместимости обеспечивает полноценно совместимую с Node.js process реализация, пришедшая на смену предыдущей минимальной реализации process, которая предоставляла только ограниченный nextTick, env, exit, getBuiltinModule, platform и features свойства.

Чтобы продолжить использовать предыдущую минимальную реализацию после даты совместимости, задайте disable_nodejs_process_v2 флаг вместо этого.

Большинство поддерживаемых Node.js свойств process реализованы там, где это возможно, а для неподдерживаемых функций экспортируется undefined. См. документация по process для получения сведений об особенностях реализации в Workers.

enable_nodejs_http_server_modules флаг включает доступность серверных модулей HTTP из Node.js, таких как node:_http_server в Workers.

disable_nodejs_http_server_modules флаг отключает доступность этих серверных модулей.

Это обеспечивает совместимость с библиотеками Node.js и существующим кодом, использующим стандартные API HTTP-сервера Node.js. Доступный функционал включает:

• http.createServer() для создания HTTP-серверов
• http.Server класс для экземпляров сервера
• http.ServerResponse для обработки ответов сервера

Этот флаг необходимо использовать вместе с enable_nodejs_http_modules флаг для включения всех возможностей node:http.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-01 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями об API Node.js HTTP.

enable_nodejs_http2_module флаг включает node:http2 заглушки модулей в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-01 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:http2 API.

Когда remove_nodejs_compat_eol включен, API, для которых в Node.js завершился жизненный цикл, удаляются для Workers. Если параметр отключен, эти API присутствуют, но могут оставаться нерабочими заглушками.

Этот флаг является сводным (roll-up). По мере того как отдельные API достигают конца поддержки (EOL) в конкретных версиях Node.js, добавляются новые флаги совместимости для этих версий (например, remove_nodejs_compat_eol_v22, remove_nodejs_compat_eol_v23, а также remove_nodejs_compat_eol_v24) которые этот флаг подразумевает начиная с соответствующих дат.

Этот флаг автоматически включается для Workers с датой совместимости 2025-09-01 или более поздней, когда nodejs_compat включён.

Когда remove_nodejs_compat_eol_v23 включен, удаляются API, чей жизненный цикл завершился в Node.js 23.x (EOL в июне 2025 года).

Этот флаг автоматически включается, когда remove_nodejs_compat_eol_v24 флаг включён после 2025-09-01.

Когда strip_authorization_on_cross_origin_redirect включен, Authorization заголовок автоматически удаляется при переходе по перенаправлению на другой источник. Такое поведение требуется текущей Спецификация Fetch API ↗.

Это требование добавили в спецификацию Fetch в 2022 году, уже после того, как Cloudflare Workers реализовали обработку fetch. Изначально Workers не соответствовали этому требованию, поэтому новое поведение включается через флаг совместимости.

Прежнее поведение не было по своей сути небезопасным и в некоторых случаях могло оказаться желательным. Например, если API, требующий авторизации, хочет перенаправить запрос на новый хост, сохранив при этом учётные данные клиента. При новом поведении такое перенаправление больше не включает учётные данные автоматически. Однако прежнее поведение могло приводить к непреднамеренной утечке учётных данных при перенаправлении на ненадёжные источники.

Чтобы сохранить прежнее поведение, задайте retain_authorization_on_cross_origin_redirect флаг.

enable_nodejs_http_modules флаг включает доступность Node.js node:http и node:https модули в Workers (только клиентские API).

disable_nodejs_http_modules флаг отключает доступность этих модулей.

Это обеспечивает совместимость с библиотеками Node.js и существующим кодом, использующим стандартные API node:http и node:https для выполнения HTTP-запросов. Доступный функционал включает:

• http.request() и https.request() для выполнения HTTP/HTTPS-запросов
• http.get() и https.get() для выполнения GET-запросов
• Объекты запроса и ответа со стандартными API Node.js
• Поддержка стандартных методов HTTP, заголовков и опций

См. документация Node.js ↗ дополнительные сведения об API Node.js.

Если expose_global_message_channel флаг установлен, Workers предоставят доступ к MessageChannel и MessagePort конструкторы глобально.

Если no_expose_global_message_channel флаг установлен, Workers не будут предоставлять их.

Если python_no_global_handlers флаг установлен, Python Workers отключают глобальные обработчики и требуют их использования через классы точек входа по умолчанию.

Когда вы включаете cache_no_cache_enabled флаг совместимости, можно указать no-cache значение для cache свойство интерфейса Request. Если этот флаг совместимости не включен или cache_option_disabled задан, среда выполнения Workers выбросит TypeError с сообщением Unsupported cache mode: no-cache.

Когда этот флаг включён, вы можете указать Cloudflare принудительно проверять актуальность ответа на подзапрос, который Worker отправляет, с помощью fetch() API:

Когда no-cache указан:

• Все запросы содержат заголовки Pragma: no-cache и Cache-Control: no-cache заданы для них.

• Подзапросы к источникам, не размещённым в Cloudflare, заставляют кеш Cloudflare выполнять повторную проверку с источником.

Ревалидация с источником означает, что запрос Worker сначала будет искать совпадение в кэше Cloudflare, а затем:

• Если совпадение найдено, на origin-сервер отправляется условный запрос, независимо от того, является ли совпадение актуальным или устаревшим. Если ресурс не изменился, возвращается кешированная версия. Если ресурс изменился, он загружается с origin-сервера, обновляется в кеше и возвращается.
• Если совпадение не найдено, Workers выполнит обычный запрос к источнику и закеширует ответ.

Примеры использования cache: 'no-cache':

const response = await fetch("https://example.com", { cache: "no-cache" });

Значение кэша также можно задать на Request объект.

const request = new Request("https://example.com", { cache: "no-cache" });
const response = await fetch(request);

Если set_event_target_this флаг установлен, Workers установят this значение обработчиков событий в EventTarget экземпляр, на котором происходит событие. Это соответствует спецификации.

Когда затем no_set_event_target_this флаг установлен, Workers не будут устанавливать this значение обработчиков событий, и оно будет undefined взамен.

Исходная версия заголовков, отправляемых в edgeworker, обрезалась до одного значения для определённых имён заголовков, таких как To и Cc. С set_forwardable_email_full_headers флаг, Workers будут получать полные значения заголовков в скрипте worker.

pedantic_wpt флаг включает строгое соответствие Web Platform Tests (WPT) в Workers. Изначально это затрагивает только Event и EventTarget API, но в будущем будет расширен на другие API. Для этого флага не задана дата включения по умолчанию.

Фрейм AsyncLocalStorage может захватывать значения, привязанные к текущему контексту запроса. Это не всегда находится под контролем пользователя, поскольку мы используем фрейм хранилища ALS для распространения внутренних участков трассировки, а также значений, заданных пользователем. Когда bind_asynclocalstorage_snapshot_to_request флаг установлен, среда выполнения привязывает снимок (snapshot) и связанные функции к текущему контексту запроса и выбросит ошибку, если связанные функции будут вызваны вне запроса, в котором они были созданы.

do_not_bind_asynclocalstorage_snapshot_to флаг отключает это поведение.

throw_on_unrecognized_import_assertion флаг определяет, как Workers обрабатывают атрибуты импорта, которые не распознаются средой выполнения. Раньше Workers игнорировали все атрибуты импорта, что не соответствует спецификации. Ожидается, что среда выполнения выбрасывает ошибку при обнаружении атрибута импорта, который не распознан.

Если ignore_unrecognized_import_assertion флаг установлен, Workers будут игнорировать нераспознанные атрибуты импорта.

Если allow_eval_during_startup флаг установлен, Workers могут использовать eval() и new Function(text) на этапе запуска скрипта Worker. Это позволяет выполнять динамический код в начале жизненного цикла Worker.

Если disallow_eval_during_startup флаг установлен, использование eval() или new Function(text) на этапе запуска вызовет ошибку.

Когда вы используете enable_request_signal флаг совместимости, можно подключить обработчик события к Request объекты, используя signal свойство ↗. Это позволяет выполнять действия в момент, когда клиент отменяет запрос к вашему Worker.

Когда cache_api_request_cf_overrides_cache_rules включен, настройки кеша, указанные в cf объект запроса, переданного в Cache API переопределяет правила кеширования. Это относится только к сайтам, принадлежащим пользователю, или сайтам с серым облаком (grey-clouded).

Это аналог Cache API для request_cf_overrides_cache_rules флаг, который применяется к fetch() API.

Если enable_navigator_language флаг установлен, navigator.language свойство будет доступно в Workers. Пока же значение navigator.language всегда будет en.

Если disable_navigator_language флаг установлен, navigator.language свойство будет недоступно.

Если disallow_importable_env флаг включён, Workers не позволят импортировать переменные окружения через cloudflare:workers модуль и не будет заполнять переменные окружения в глобальном process.env объект, когда включена совместимость с Node.js.

У этого флага нет даты включения по умолчанию.

Включает использование FinalizationRegistry ↗ и WeakRef ↗ встроенных модулей.

• FinalizationRegistry позволяет зарегистрировать callback для очистки, который выполняется после сборки объекта мусорщиком.
• WeakRef создаёт слабую ссылку на объект, позволяя сборщику мусора удалить его, если не осталось других сильных ссылок.

:::note[Behaviour] FinalizationRegistry callback функции очистки могут выполняться в любой момент жизненного цикла запроса, даже после завершения вызванного обработчика (аналогично ctx.waitUntil()). У этих обратных вызовов нет связанного асинхронного контекста. Внутри них нельзя выполнять операции ввода-вывода, включая отправку событий в tail Worker. :::

:::caution Эти API принципиально недетерминированы. Время и порядок выполнения сборки мусора непредсказуемы, и вы не следует полагаться на них в критически важной логике программы. Кроме того, коллбэки очистки, зарегистрированные через FinalizationRegistry может никогда не выполняется, включая, помимо прочего, случаи, когда сборка мусора не запускается или ваш Worker вытесняется. :::

Если request_signal_passthrough флаг, AbortSignal входящего запроса будет передан подзапросам, когда запрос перенаправляется в подзапрос с помощью fetch() API.

Слово «the» no_request_signal_passthrough флаг установлен, AbortSignal входящего запроса не будет передан.

Исходный URLPattern реализация не полностью соответствовала WHATWG URLPattern Standard ↗, что приводило к ряду проблем, о которых сообщали пользователи.

С urlpattern_standard включено, Workers использует реализацию URLPattern, соответствующую спецификации. Это критическое изменение по сравнению с исходным поведением, поэтому оно скрыто за флагом совместимости.

Если вы используете URLPattern и после обновления даты совместимости заметили неожиданные изменения в поведении, можно задать urlpattern_original чтобы вернуться к предыдущей реализации.

Для Workers с статические ресурсы и при включённом этом флаге совместимости запросы навигации (запросы, у которых есть Sec-Fetch-Mode: navigate заголовок) будет предпочтительно обслуживаться нашей логикой отдачи ассетов, даже если точное совпадение ассета не найдено. Это особенно полезно для приложений, которые работают в Режим одностраничного приложения (SPA) или иметь пользовательские страницы 404, поскольку теперь это означает, что резервные страницы 200 /index.html и 404 /404.html будет отдан до вызова скрипта Worker и поэтому не повлечёт списания средств.

Без этого флага среда выполнения по-прежнему будет использовать старое поведение: вызывать скрипт Worker (если он есть) для любых запросов, которые точно не совпадают со статическим ресурсом.

Когда assets.run_worker_first = true задан, этот флаг совместимости не оказывает никакого действия. assets.run_worker_first = true настройка гарантирует, что скрипт Worker выполняется раньше любой логики раздачи ресурсов.

Когда вы включаете nodejs_compat_populate_process_env флаг совместимости и nodejs_compat флаг также включён, process.env будет заполнен значениями из любых привязок с текстовыми или JSON значениями. Это означает, что если вы добавили переменные окружения, секреты, или метаданные версии привязок, эти значения доступны через process.env.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

Это упрощает доступ к этим значениям и соответствует распространенным шаблонам Node.js, что может снизить трудозатраты и повысить совместимость с существующими библиотеками Node.js.

Если пользователи не хотят, чтобы эти значения были доступны через process.env, они могут использовать nodejs_compat_do_not_populate_process_env флаг. В этом случае process.env всё ещё будет доступен, но значения не будут добавляться автоматически.

Если disallow_importable_env флаг совместимости установлен, process.env также не будет заполнен.

По умолчанию Queues Consumer Workers подтверждают получение сообщений только после того, как промисы, переданные в ctx.waitUntil() были выполнены. Из-за этого потребители очереди, использующие ctx.waitUntil() для медленной обработки сообщений. Поведение по умолчанию описано в разделе Руководство по настройке потребителя Queues.

Этот Consumer Worker показывает пример Worker, который использует ctx.waitUntil(). При поведении по умолчанию этот Worker-потребитель подтверждает пакет сообщений только после завершения функции sleep.

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Если queue_consumer_no_wait_for_wait_until флаг включён, потребители Queues больше не будут ожидать промисы, переданные в ctx.waitUntil() до разрешения, прежде чем подтверждать сообщения. Это может повысить производительность потребителей очереди, использующих ctx.waitUntil(). При включённом флаге в примере выше Worker-потребитель подтвердит пакет, не дожидаясь завершения функции sleep.

Использование этого флага не повлияет на поведение ctx.waitUntil(). ctx.waitUntil() продолжит продлевать время жизни вашего Worker-потребителя, чтобы он продолжал работать даже после подтверждения пакета сообщений.

Исходная реализация TransformStream содержала ошибку, из-за которой сигнализация backpressure переставала работать после первой записи в transform. К сожалению, это исправление может привести к сбою существующего кода, написанного для устранения этой ошибки, что и приведёт к сбою. Поэтому fixup-transform-stream-backpressure флаг совместимости добавлен, чтобы включить это исправление.

Исправление включено по умолчанию для дат совместимости 2024-12-16 и позднее.

Чтобы восстановить исходную логику backpressure, отключите исправление с помощью original-transform-stream-backpressure флаг.

Workers реализует возможность использовать Node.js-подобный require(...) метод для импорта модулей в бандл Worker. Исторически этот механизм позволял импортируемым модулям использовать top-level await. Однако это не совместимо с Node.js.

disable_top_level_await_in_require флаг совместимости приведёт к тому, что require() завершаться ошибкой, если модуль использует await верхнего уровня. Этот флаг включён по умолчанию при дате совместимости 2024-12-02 или более поздней.

Чтобы восстановить исходное поведение, разрешающее await верхнего уровня, используйте enable_top_level_await_in_require флаг совместимости.

Когда вы включаете cache_option_enabled флаг совместимости, можно указать значение для cache свойство интерфейса Request. Если этот флаг совместимости не включен или cache_option_disabled задан, среда выполнения Workers выбросит Error с сообщением The 'cache' field on 'RequestInitializerDict' is not implemented.

Когда этот флаг включён, вы можете указать Cloudflare не кэшировать ответ на подзапрос, который Worker отправляет, с помощью fetch() API:

Единственная опция кеша, включённая с cache_option_enabled это 'no-store'. Указание любого другого значения приведёт к тому, что Workers runtime выбросит TypeError с сообщением Unsupported cache mode: <the-mode-you-specified>.

Когда no-store указан:

• Все запросы содержат заголовки Pragma: no-cache и Cache-Control: no-cache заданы для них.

• Подзапросы к источникам, не размещённым в Cloudflare, обходят кеш Cloudflare.

Примеры использования cache: 'no-store':

const response = await fetch("https://example.com", { cache: "no-store" });

Значение кэша также можно задать на Request объект.

const request = new Request("https://example.com", { cache: "no-store" });
const response = await fetch(request);

Если global_fetch_strictly_public флаг совместимости включён, глобальный fetch() функция будет строго маршрутизировать запросы так, как если бы они были сделаны из публичного интернета.

Это означает, что запросы к собственной зоне Worker вернутся к «парадному входу» Cloudflare и будут обработаны как запрос из интернета, возможно, даже снова попав в тот же Worker.

Если global_fetch_strictly_public не включен, такие запросы направляются на исходный сервер зоны, минуя любые Workers, привязанные к этому URL, а также настройки безопасности Cloudflare.

Раньше промис можно было разрешить из неверного контекста запроса, из-за чего продолжения промиса могли планироваться в неправильном контексте, что приводило к ошибкам и трудно диагностируемым дефектам.

С handle_cross_request_promise_resolution включено, продолжения промисов планируются на выполнение в правильном контексте запроса, если он ещё активен, либо отбрасываются с предупреждением, если правильный контекст уже завершился.

Методы HTTP должны указываться в верхнем регистре. Согласно спецификации fetch, если метод указан как get, post, put, delete, head, или options, ожидается, что реализации приведут метод к верхнему регистру. Все остальные имена методов обычно должны вызывать ошибку как нераспознанные (например, patch будет ошибкой при PATCH допускается). Это несколько ограничивает возможности, даже если так предусмотрено спецификацией. Этот флаг изменяет поведение так, что все методы приводятся к верхнему регистру перед разбором, поэтому метод всегда распознаётся, если он является известным методом.

Чтобы восстановить стандартное поведение, используйте no_upper_case_all_http_methods флаг совместимости.

Было внесено изменение для установки Symbol.toStringTag во всех объектах Workers API, чтобы исправить несколько ошибок соответствия спецификации. К сожалению, это изменение оказалось более критичным, чем ожидалось. Объект do_not_set_tostring_tag флаг совместимости восстанавливает исходное поведение при датах совместимости 2024-09-26 или более ранних.

nodejs_zlib флаг включает node:zlib модуль в Workers.

Этот флаг автоматически включается для Workers с датой совместимости 2024-09-23 или более поздней, когда nodejs_compat включён.

См. документация Node.js ↗ с подробностями о node:zlib API.

Когда этот флаг включён и при выполнении подзапроса вы указываете порт с помощью fetch() API, будет использован указанный вами номер порта.

Если вы выполняете подзапрос к сайту, который использует Cloudflare («Orange Clouded»), допускается только порты, поддерживаемые обратным прокси Cloudflare можно указать. При попытке указать неподдерживаемый порт он будет проигнорирован.

Если вы выполняете подзапрос к сайту, который не использует Cloudflare («Grey Clouded»), можно указать любой порт.

Например:

const response = await fetch("https://example.com:8000");

С allow_custom_ports приведенный выше пример выполнит fetch https://example.com:8000 вместо https://example.com:443.

Обратите внимание, что создание клиента WebSocket с помощью вызова new WebSocket(url) также будет учитывать этот флаг.

При использовании исходной реализации WritableStream (потоков «internal»), abort() операция раньше обрабатывалась лениво, то есть очередь ожидающих записей не очищалась до следующей обработки очереди. Из-за этого поток мог зависнуть, если потребитель прекращал чтение.

С internal_writable_stream_abort_clears_queue включено, очередь очищается сразу после abort(), предотвращая зависания в случаях, когда потребитель прекратил обработку записей.

При вызове response.blob.type(), тип MIME теперь будет корректно извлекаться из content-type заголовки, согласно спецификация WHATWG ↗.

fetch_standard_url флаг делает fetch() используйте WHATWG URL Standard ↗ правила разбора. Исходная реализация выбрасывала исключение TypeError: Fetch API cannot load ошибки для некоторых URL-адресов, для которых стандартный парсинг их не выдаёт, например при наличии пробелов перед URL. Теперь ошибки URL будут выбрасываться сразу же при вызове new Request() с неверным URL. Ранее ошибки URL выбрасывались только один раз fetch() был вызван.

В исходной реализации BYOB («Bring your own buffer») ReadableStreams, read() метод вернул бы undefined когда поток был закрыт и данных для чтения больше не оставалось. Такое поведение не соответствовало стандарту ReadableStream поведение, которое возвращает пустой Uint8Array при закрытии потока.

Если internal_stream_byob_return_view флаг используется, BYOB read() реализует стандартное поведение.

const resp = await fetch('https://example.org');
const reader = resp.body.getReader({ mode: 'byob' });
await result = await reader.read(new Uint8Array(10));

if (result.done) {
  // The result gives us an empty Uint8Array...
  console.log(result.value.byteLength); // 0

  // However, it is backed by the same underlying memory that was passed
  // into the read call.
  console.log(result.value.buffer.byteLength); // 10
}

Если brotli_content_encoding флаг совместимости включён, Workers поддерживает br кодировку содержимого и может отправлять запросы и получать ответы с данными, закодированными с помощью Brotli ↗ алгоритм сжатия. Это уменьшает объём данных, которые нужно получить, а также позволяет передавать клиенту исходные сжатые данные без изменений. См. Fetch API документация для получения подробностей.

При включенном флаге Durable Object заглушки и Service Bindings поддерживают RPC. Это означает, что такие объекты теперь выглядят так, будто в них определены все возможные имена методов. Вызов любого имени метода отправляет RPC удалённому Durable Object или сервису Worker.

Для большинства приложений это изменение не повлияет на работу, если вы его не используете. Однако некоторый существующий код может пострадать, если он явно проверяет наличие имён методов, ранее не определённых в этих типах. Например, встречался код, который перебирает привязки и пытается автоматически определить их типы по тому, какие методы они реализуют. Теперь такой код будет считать, что service bindings реализуют любой метод, поэтому может ошибочно принимать service bindings за другой тип. В известных нам случаях это не приводило к реальным сбоям, но из осторожности мы скрываем это изменение за флагом.

С unwrap_custom_thenables флаг, различные API Workers, принимающие промисы, также будут корректно обрабатывать пользовательские thenable-объекты (объекты с then метод), которые не являются нативными promise, но должны обрабатываться как таковые). Например, waitUntil метод объекта ExecutionContext объект корректно обрабатывает пользовательские thenable-объекты, позволяя использовать их вместо нативных promise.

async fetch(req, env, ctx) {
  ctx.waitUntil({ then(res) {
    // Resolve the thenable after 1 second
    setTimeout(res, 1000);
  } });
  // ...
}

Durable Object заглушки и Service Bindings оба реализуют fetch() метод, который ведёт себя аналогично глобальному fetch() метод, но запросы отправляются на назначение, представленное объектом, а не маршрутизируются на основе URL.

Исторически объекты API, имевшие такой fetch() метод также имел методы get(), put(), а также delete(). Эти методы были тонкими обёртками вокруг fetch() который выполнит соответствующий HTTP метод и автоматически обработает запись/чтение тела запроса и ответа при необходимости.

Эти методы появились как ранняя идея много лет назад, но так и не были документированы, поэтому использовались редко (если вообще использовались). Включение fetcher_no_get_put_delete, либо установив дату совместимости не ранее 2024-03-26 отключает эти методы для вашего Worker.

Это изменение открывает возможность в будущем определять собственные методы с такими именами. Без этого изменения вы не смогли бы определить собственный get, put, а также delete методы, поскольку они будут конфликтовать с этими встроенными вспомогательными методами.

С queues_json_messages флаг, привязки Queue будут сериализовать значения, переданные в send() или sendBatch() в формат JSON по умолчанию (если не указан конкретный contentType указан).

Подавляет глобальный importScripts() функция. Этот метод был включён в глобальную область видимости Workers, но явно помечен как нереализованный. Однако наличие этой функции могло вызывать проблемы у некоторых библиотек. Этот флаг совместимости удаляет функцию из глобальной области видимости.

Включает доступность Node.js AsyncLocalStorage ↗ API в Workers.

Этот флаг включает полноценную поддержку Python. Python Workers реализуют большую часть модуля Python стандартная библиотека, поддерживают все привязки, переменная окружения, а также секреты, и интеграцию с объектами и функциями JavaScript через интерфейс внешних функций.

В WebCrypto API publicExponent поле алгоритма ключей RSA раньше было ArrayBuffer. Используя этот флаг, publicExponent это Uint8Array как того требует спецификация.

Заданное значение в vectorize_query_metadata_optional означает, что операция запроса Vectorize должна принимать более новые аргументы с returnValues и returnMetadata заданный отдельно вместо устаревшего аргумента returnVectors. Это также меняет формат возвращаемого значения. Если для возврата были указаны значения векторов, возвращаемое значение теперь представляет собой развёрнутый объект вектора с score прикреплён там, где раньше содержался вложенный векторный объект.

Среда выполнения Workers не поддерживала сжатие WebSocket на момент выхода первой реализации WebSocket. Исторически среда выполнения удаляла или игнорировала Sec-WebSocket-Extensions заголовок, но теперь может полностью соответствовать WebSocket Compression RFC. Поскольку многие клиенты, вероятно, отправляют Sec-WebSocket-Extensions: permessage-deflate своим Workers уже сегодня (new WebSocket(url) автоматически устанавливает это в браузерах), мы решили сохранить прежнее поведение, если этот флаг отсутствует.

Если этот флаг указан, среда выполнения Workers может использовать сжатие WebSocket как для входящих, так и для исходящих соединений WebSocket.

Подобно браузерам, вызов new WebSocket(url) в Worker автоматически устанавливает Sec-WebSocket-Extensions: permessage-deflate заголовок. Если вы используете нестандартный fetch() API для получения WebSocket можно указать Sec-WebSocket-Extensions заголовок со значением permessage-deflate и включить любые параметры сжатия, определённые в RFC-7692 ↗.

Выполнять дополнительную проверку ошибок в Web Crypto API для соответствия спецификации и отклонять потенциально небезопасные параметры ключа:

• При генерации ключей RSA их размер должен быть кратен 128 битам, иначе boringssl может усечь ключ.
• Размер импортированных ключей RSA должен быть не менее 256 бит и не более 16384 бит, как и у вновь создаваемых ключей.
• Открытая экспонента для импортированных ключей RSA ограничена часто используемыми значениями [3, 17, 37, 65537].
• В соответствии со спецификацией при попытке импортировать открытый ключ ECDH с непустым списком usages будет выброшена ошибка.

Выполнять дополнительную проверку ошибок в Compression Streams API и выбрасывать ошибку, если DecompressionStream содержит завершающие данные или закрывается до того, как были предоставлены все сжатые данные.

Этот флаг изменяет поведение кеша при запросе ресурсов через Fetch API. Настройки кеша, указанные в request.cf объект, например cacheEverything и cacheTtl, теперь имеют приоритет над любыми Cache Rules задан.

Этот флаг оптимизирует запросы Workers, сокращая количество лишних свойств в request.cf объект.

Если флаг включен, будь то по умолчанию после 2023-08-01 или в результате установки no_cf_botmanagement_default флаг: Cloudflare будет включать только Объект Bot Management в Worker request.cf если у аккаунта есть доступ к Bot Management.

При отключенном флаге Cloudflare будет включать объект Bot Management по умолчанию независимо от того, включен ли Bot Management в тарифе аккаунта.

WHATWG добавил дополнительные необязательные аргументы в URLSearchParams объект delete() ↗ и has() ↗ методы, позволяющие точнее контролировать удаление параметров запроса. Поскольку аргументы необязательны и меняют поведение методов при их наличии, есть риск сломать существующий код. Если дата совместимости установлена на 1 июля 2023 года или позже, этот флаг совместимости будет включён по умолчанию.

Пример того, как это изменение может сломать существующий код, рассмотрите код, использующий Array forEach() метод для перебора нескольких параметров, которые нужно удалить:

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach(usp.delete.bind(usp));

forEach() автоматически передаёт несколько параметров в переданную функцию. До появления новых стандартных параметров эти дополнительные аргументы просто игнорировались.

Однако теперь дополнительные аргументы имеют значение и меняют поведение функции. С этим флагом пример выше пришлось бы изменить так:

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach((key) => usp.delete(key));

Измените реализацию URL, используемую в Response.redirect() соответствовать спецификации (WHATWG URL Standard).

Ранее при использовании Workers for Platforms API динамической диспетчеризации чтобы отправить HTTP-запрос пользовательскому Worker. Если пользовательский Worker выбросил исключение, Worker динамической диспетчеризации получит HTTP 500 ошибку без тела. Когда dynamic_dispatch_tunnel_exceptions флаг совместимости включён, исключение вместо этого будет передано обратно в Worker динамической маршрутизации. fetch() вызов в Worker динамической маршрутизации выбросит то же исключение. Это соответствует аналогичному поведению привязки к сервисам и Durable Objects.

Добавляет getSetCookie() ↗ метод к Headers ↗ API в Workers.

const response = await fetch("https://example.com");
let cookieValues = response.headers.getSetCookie();

Включает API Node.js в Workers Runtime. Для дат совместимости 2026-08-04 или более поздней версии Workers включает оба nodejs_compat и nodejs_compat_v2 по умолчанию.

Обратите внимание, что некоторые API Node.js включаются только тогда, когда дата совместимости Worker не раньше следующих дат:

Некоторые модули Node.js доступны в Workers только в виде нерабочих заглушек. Их можно импортировать или подключить через require, но они не содержат рабочей реализации соответствующих API Node.js. Заглушки существуют для совместимости с пакетами, которые проверяют наличие модуля, и не предназначены для прямого использования в коде приложения.

Следующие stubs включаются автоматически, только если nodejs_compat включен, а дата совместимости вашего Worker совпадает с указанной или более поздняя:

При включении nodejs_compat, рекомендуем использовать последнюю версию Wrangler CLI, и самую последнюю compatibility date для максимальной совместимости. Некоторые старые версии Wrangler добавляют дополнительные полифиллы, которые больше не нужны, если ваш Worker использует более позднюю compatibility date, поскольку их уже предоставляет среда выполнения Workers.

Для дат совместимости 2026-08-04 или более поздней версии, nodejs_compat и nodejs_compat_v2 не используются, потому что compatibility date включает такое же поведение. Существующим проектам не нужно удалять эти флаги при обновлении compatibility date. Чтобы полностью отключить совместимость с Node.js, удалите положительные флаги, если они заданы. Затем добавьте оба no_nodejs_compat и no_nodejs_compat_v2.

Если при использовании определённого npm-пакета в Workers у вас возникают ошибки, сначала попробуйте обновить дату совместимости и использовать последнюю версию Wrangler CLI или Cloudflare Vite Plugin. Если проблема сохраняется, сообщите об этом через создание issue на GitHub ↗.

Добавляет незавершенную new ReadableStream() и new WritableStream() конструкторы, работающие поверх базовых источников и приёмников JavaScript.

Ранее new TransformStream() конструктор не соответствовал стандарту Streams API. Используйте transformstream_enable_standard_constructor чтобы включить обратно несовместимое изменение, приводящее конструктор в соответствие. Должен использоваться вместе с streams_enable_constructors флаг.

Ранее модули CommonJS экспортировали пространство имен модуля (объект наподобие { default: module.exports }) а не экспортировать только module.exports. Когда этот флаг включён, экспорт фиксируется.

capture_async_api_throws флаг совместимости гарантирует, что в соответствии со стандартным API async-функции будут отклоняться только при выбросе ошибки. Обратный do_not_capture_async_api_throws флаг означает, что асинхронные функции, содержащие ошибку, могут выбрасывать эту ошибку синхронно, а не отклонять промис.

Исходная реализация URL ↗ API в Workers не полностью соответствовал WHATWG URL Standard ↗, отличаясь в нескольких аспектах, включая:

• Исходная реализация схлопывала последовательности из нескольких слэшей в один слэш:

  new URL("https://example.com/a//b").toString() === "https://example.com/a/b"

• Исходная реализация выбрасывала "TypeError: Invalid URL string." если были обнаружены некорректные percent-encoded escape последовательности, например https://example.com/a%%b.

• Исходная реализация по-другому выполняла percent-encode или percent-decode для некоторого содержимого:

  new URL("https://example.com/a%40b?c d%20e?f").toString() === "https://example.com/a@b?c+d+e%3Ff"

• В исходной реализации отсутствовали более поздние URL функции, такие как URL.canParse() ↗.

Установите compatibility date вашего Worker на дату после 2022-10-31 или включите url_standard флаг совместимости, чтобы включить полностью соответствующий спецификации URL реализация API.

См. response_redirect_url_standard флаг совместимости , что влияет на реализацию URL, используемую в Response.redirect().

С r2_list_honor_include флаг, include аргумент в R2 list параметры учитываются. При более старой дате совместимости и без этого флага include аргумент неявно ведёт себя как include: ["httpMetadata", "customMetadata"].

В рантайме была ошибка, из-за которой при передаче во встроенные API недопустимые значения иногда ошибочно приводились к null. Вместо этого TypeError должно было быть выброшено исключение. dont_substitute_null_on_type_error исправляет это поведение, чтобы в таких случаях корректно выбрасывалась ошибка.

С minimal_subrequests флаг, fetch() подзапросы, отправляемые к эндпоинтам в собственной зоне Worker (также называемые подзапросами в пределах одной зоны), применяются с урезанным набором функций. В целом эти функции изначально не должны были применяться к подзапросам в пределах одной зоны, и заметных для пользователя изменений в поведении ожидается очень мало. В частности, при использовании нового флага Workers могут столкнуться со следующими изменениями поведения:

• Тела ответов больше не будут по возможности сжиматься gzip перед передачей в среду выполнения Workers. Если Worker считывает тело ответа, он получит его в виде обычного текста, как и раньше, поэтому отключение этой настройки избавляет от лишней декомпрессии. Если же Worker просто передаёт ответ клиенту, HTTP-прокси Cloudflare по возможности сжимает тело ответа gzip уже на своей стороне, за пределами среды выполнения Workers. Изменение в поведении, которое может заметить скрипт Worker, состоит в том, что некоторые Content-Encoding: gzip заголовки больше не будут появляться.
• Ранее Automatic Platform Optimization в некоторых случаях могла применяться как к исходному запросу Worker, так и к его подзапросам. Теперь она будет применяться только к исходному запросу.
• Теперь предзагрузка ссылок применяется только к ответу Worker, а не к ответам на подзапросы Worker.

С global_navigator флаг, новый глобальный navigator свойство доступно внутри Workers. На данный момент оно предоставляет только одно navigator.userAgent свойство, значение которого установлено в 'Cloudflare-Workers'. Это свойство можно использовать для надёжного определения того, выполняется ли код в среде Workers.

no_cots_on_external_fetch флаг отключает использование Custom Origin Trust Store при выполнении внешних (grey-clouded) подзапросов из Cloudflare Worker.

Изначально свойства объектов Workers API определялись как свойства экземпляра, а не свойства прототипа. Это нарушало возможность наследования на уровне JavaScript и не позволяло подклассу корректно переопределять геттеры и сеттеры суперкласса. Этот флаг отвечает за критическое изменение, благодаря которому эти геттеры и сеттеры задаются в шаблоне прототипа.

Это изменение применяется к:

• AbortSignal
• AbortController
• Blob
• Body
• DigestStream
• Event
• File
• Request
• ReadableStream
• ReadableStreamDefaultReader
• ReadableStreamBYOBReader
• Response
• TextDecoder
• TextEncoder
• TransformStream
• URL
• WebSocket
• WritableStream
• WritableStreamDefaultWriter

Изначально при отправке запроса к Durable Object с помощью вызова stub.fetch(url), в качестве входных данных принимался относительный URL. Такой URL интерпретировался относительно URL-заполнителя http://fake-host, и итоговый абсолютный URL передавался в fetch() обработчик. Такое поведение было ошибочным: полные URL должны были быть обязательными. Этот флаг делает полные URL обязательными.

Изначально, если fetch() функции был передан URL, задающий протокол, отличный от http: или https:, он молча обработает его так, как если бы это был http:. Например, fetch() предположительно принимает ftp: URL, но на самом деле выполнял HTTP-запросы.

Обратите внимание, что Cloudflare Workers поддерживает нестандартное расширение для fetch() чтобы добавить поддержку WebSocket. Однако при HTTP-запросе, предназначенном для инициации WebSocket-рукопожатия, всё равно следует использовать http: или https: в качестве протокола, а не ws: ни wss:.

ws: и wss: Схемы URL предназначены для использования вместе с new WebSocket() конструктор, который поддерживает исключительно WebSocket. Расширение для fetch() спроектирован для поддержки HTTP и WebSocket в рамках одного запроса (ответ может как инициировать переход на WebSocket, так и не делать этого), поэтому все запросы рассматриваются как HTTP.

Изначально среда выполнения Workers не отсоединяла ArrayBuffers из предоставленных пользователем TypedArrays при использовании BYOB-ридера read() метод, как того требует спецификация Streams, а значит, можно было случайно повторно использовать один и тот же буфер для нескольких read() вызовы. Это изменение приводит Workers в соответствие со спецификацией.

Пользовательский код никогда не должен пытаться повторно использовать ArrayBuffer который был передан в BYOB-ридера read() метод. Вместо этого пользовательский код может повторно использовать ArrayBuffer лежащий в основе результата read() Promise, как показано в примере ниже.

// Consume and discard `readable` using a single 4KiB buffer.
let reader = readable.getReader({ mode: "byob" });
let arrayBufferView = new Uint8Array(4096);
while (true) {
  let result = await reader.read(arrayBufferView);
  if (result.done) break;
  // Optionally something with `result` here.
  // Re-use the same memory for the next `read()` by creating
  // a new Uint8Array backed by the result's ArrayBuffer.
  arrayBufferView = new Uint8Array(result.value.buffer);
}

Более новый метод расширения readAtLeast() всегда отсоединяет ArrayBuffer и не зависит от этого флага функции.

FormData API ↗ используется для разбора данных (особенно тела HTTP-запросов) в multipart/form-data формате.

Первоначально в среде выполнения Workers реализация FormData API некорректно преобразовывал загруженные файлы в строки. Поэтому formData.get("filename") вернёт строку с содержимым файла вместо File объект. Это изменение устраняет проблему, поскольку файлы теперь представляются с помощью File как указано в стандарте.

Стандарт HTML5 определяет фиксированный набор элементов как «пустые» (void elements), то есть без закрывающего тега: <area>, <base>, <br>, <col>, <command>, <embed>, <hr>, <img>, <input>, <keygen>, <link>, <meta>, <param>, <source>, <track>, а также <wbr>.

HTML5 не поддерживает синтаксис самозакрывающихся тегов XML. Например, <script src="foo.js" /> не задает элемент script без тела. Тег </script> закрывающий тег всё равно обязателен. /> синтаксис вообще не распознается HTML5 и обрабатывается так же, как >. Однако многие разработчики по-прежнему предпочитают этот синтаксис как наследие XHTML, стандарта, который не прижился в начале 2000-х годов.

<esi:include> и <esi:comment> это два тега, которые не входят в стандарт HTML5, а используются как часть Edge Side Includes ↗, технология для модификации HTML на стороне сервера. Такие теги обычно не содержат тела и, как правило, записываются с использованием самозакрывающегося синтаксиса XML.

HTMLRewriter спроектирован для разбора стандартного HTML5, а не ESI. Однако было бы полезно реализовать некоторые части ESI с помощью HTMLRewriter. Для этого данный флаг совместимости приводит к тому, что HTMLRewriter чтобы обрабатывать <esi:include> и <esi:comment> как void-теги, чтобы их можно было корректно разбирать и обрабатывать.

Эти флаги можно включить через compatibility_flags, но пока не запланированы стать поведением по умолчанию к какой-либо конкретной дате.

По умолчанию Queues Consumer Workers подтверждают получение сообщений только после того, как промисы, переданные в ctx.waitUntil() были выполнены. Из-за этого потребители очереди, использующие ctx.waitUntil() для медленной обработки сообщений. Поведение по умолчанию описано в разделе Руководство по настройке потребителя Queues.

Этот Consumer Worker показывает пример Worker, который использует ctx.waitUntil(). При поведении по умолчанию этот Worker-потребитель подтверждает пакет сообщений только после завершения функции sleep.

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Если queue_consumer_no_wait_for_wait_until флаг включён, потребители Queues больше не будут ожидать промисы, переданные в ctx.waitUntil() до разрешения, прежде чем подтверждать сообщения. Это может повысить производительность потребителей очереди, использующих ctx.waitUntil(). При включённом флаге в примере выше Worker-потребитель подтвердит пакет, не дожидаясь завершения функции sleep.

Использование этого флага не повлияет на поведение ctx.waitUntil(). ctx.waitUntil() продолжит продлевать время жизни вашего Worker-потребителя, чтобы он продолжал работать даже после подтверждения пакета сообщений.

Стандарт HTML5 определяет фиксированный набор элементов как «пустые» (void elements), то есть без закрывающего тега: <area>, <base>, <br>, <col>, <command>, <embed>, <hr>, <img>, <input>, <keygen>, <link>, <meta>, <param>, <source>, <track>, а также <wbr>.

HTML5 не поддерживает синтаксис самозакрывающихся тегов XML. Например, <script src="foo.js" /> не задает элемент script без тела. Тег </script> закрывающий тег всё равно обязателен. /> синтаксис вообще не распознается HTML5 и обрабатывается так же, как >. Однако многие разработчики по-прежнему предпочитают этот синтаксис как наследие XHTML, стандарта, который не прижился в начале 2000-х годов.

<esi:include> и <esi:comment> это два тега, которые не входят в стандарт HTML5, а используются как часть Edge Side Includes ↗, технология для модификации HTML на стороне сервера. Такие теги обычно не содержат тела и, как правило, записываются с использованием самозакрывающегося синтаксиса XML.

HTMLRewriter спроектирован для разбора стандартного HTML5, а не ESI. Однако было бы полезно реализовать некоторые части ESI с помощью HTMLRewriter. Для этого данный флаг совместимости приводит к тому, что HTMLRewriter чтобы обрабатывать <esi:include> и <esi:comment> как void-теги, чтобы их можно было корректно разбирать и обрабатывать.