← Cloudflare Workers / workers / configuration / routing

Маршруты

Маршруты позволяют связать шаблон URL с Worker. Когда в сеть Cloudflare поступает запрос, соответствующий указанному шаблону URL, ваш Worker выполняется на этом маршруте.

Маршруты представляют собой набор правил, которые проверяются по URL запроса. Их рекомендуется использовать, если у вас есть выделенный сервер приложений, с которым вы всегда должны взаимодействовать. Вызов fetch() для входящего Request объект инициирует подзапрос (subrequest) к серверу приложения, как указано в DNS настройки вашей зоны Cloudflare.

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

Маршруты могут fetch() Custom Domains и обладают более высоким приоритетом, если настроены для одного и того же хоста. Если вы хотите разместить перед приложением логирующий Worker, вы можете, например, создать Custom Domain для Worker приложения на app.example.com, и создайте маршрут (Route) для вашего логирующего Worker по адресу app.example.com/*. Вызов fetch() вызовет Worker приложения на вашем Custom Domain. Обратите внимание, что маршруты не могут быть целью для одной зоны fetch() вызов.

Чтобы добавить маршрут, у вас должно быть:

1. Одна активная зона Cloudflare.
2. Worker для вызова.
3. DNS запись, настроенная для домен или поддомен проксируемые Cloudflare (также известные как с оранжевым облаком) на который вы хотите направлять маршрут.

Если ваш Worker не является источником вашего приложения, следуйте инструкциям ниже, чтобы настроить маршрут.

Прежде чем настроить маршрут, убедитесь, что у вас настроена DNS-запись для домен или поддомен хотите перенаправлять.

Чтобы настроить маршрут в дашборде:

Прежде чем настроить маршрут, убедитесь, что у вас настроена DNS-запись для домен или поддомен хотите перенаправлять.

Чтобы настроить маршрут с помощью конфигурационный файл Wrangler, см. следующий пример.

{
	"routes": [
		{
			"pattern": "subdomain.example.com/*",
			"zone_name": "example.com"
		},
		// or
		{
			"pattern": "subdomain.example.com/*",
			"zone_id": "<YOUR_ZONE_ID>"
		}
	]
}

[[routes]]
pattern = "subdomain.example.com/*"
zone_name = "example.com"

[[routes]]
pattern = "subdomain.example.com/*"
zone_id = "<YOUR_ZONE_ID>"

Добавьте zone_name или zone_id параметр после каждого маршрута. zone_name и zone_id параметры взаимозаменяемы. Если используется zone_id, найдите свой zone ID следующим образом:

Чтобы добавить несколько маршрутов:

{
	"routes": [
		{
			"pattern": "subdomain.example.com/*",
			"zone_name": "example.com"
		},
		{
			"pattern": "subdomain-two.example.com/example",
			"zone_id": "<YOUR_ZONE_ID>"
		}
	]
}

[[routes]]
pattern = "subdomain.example.com/*"
zone_name = "example.com"

[[routes]]
pattern = "subdomain-two.example.com/example"
zone_id = "<YOUR_ZONE_ID>"

Шаблоны маршрутов выглядят так:

https://*.example.com/images/*

Этот шаблон соответствует всем HTTPS запросам к субдомену example.com, пути которых начинаются с /images/.

Шаблон, соответствующий всем запросам, выглядит так:

*example.com/*

Хотя они похожи на регулярное выражение ↗ шаблон, шаблоны маршрутов подчиняются определённым правилам:

• Единственный поддерживаемый оператор: подстановочный знак (*), что соответствует нулю или более любых символов.

• Шаблоны маршрутов не могут содержать инфиксные подстановочные знаки или параметры запроса. Например, ни example.com/*.jpg ни example.com/?foo=* являются допустимыми шаблонами маршрутов.

• Если под URL запроса подходит больше одного паттерна маршрута, побеждает наиболее специфичный. Например, паттерн www.example.com/* будет иметь приоритет над *.example.com/* при сопоставлении запроса к https://www.example.com/. Шаблон example.com/hello/* будет иметь приоритет над example.com/* при сопоставлении запроса к example.com/hello/world.

• Сопоставление шаблонов маршрутов учитывает весь URL запроса, включая строку параметров запроса. Поскольку шаблоны маршрутов не могут содержать параметры запроса, единственный способ сопоставить шаблон маршрута с URL, содержащими параметры запроса, это завершить его подстановочным знаком *.

• Компонент пути в шаблонах маршрутов чувствителен к регистру, например, example.com/Images/* и example.com/images/* это два разных маршрута.

• Для маршрутов, созданных до 15 октября 2023 года, компонент host в шаблонах маршрутов чувствителен к регистру, например example.com/* и Example.com/* это два разных маршрута.

• Для маршрутов, созданных 15 октября 2023 года или позже, компонент host в шаблонах маршрутов не чувствителен к регистру, например example.com/* и Example.com/* являются эквивалентными маршрутами.

Маршрут можно задать, не привязывая его к Worker. Такой маршрут будет отменять действие менее конкретных шаблонов. Например, рассмотрим пару шаблонов маршрутов: один со скриптом Workers, другой без него:

*example.com/images/cat.png -> <no script>
*example.com/images/*       -> worker-script

В этом примере все запросы, предназначенные для example.com и пути которых начинаются с /images/ будет перенаправлен на worker-script, кроме для /images/cat.png, который бы полностью обошёл Workers. Запросы с путём /images/cat.png?foo=bar будет перенаправлен на worker-script, из-за наличия строки запроса.

Следующий набор правил определяет допустимость паттерна маршрута.

Если ваша зона example.com, тогда простейшим возможным шаблоном маршрута будет example.com, который бы соответствовал http://example.com/ и https://example.com/, и ничего больше. Как и в случае с URL, подразумевается путь / если вы его не укажете.

Например, https://example.com/?anything не является допустимым шаблоном маршрута.

Если вы не укажете схему в шаблоне маршрута, он будет соответствовать обоим http:// и https:// URL. Если вы включите http:// или https://, он будет соответствовать только запросам HTTP или HTTPS соответственно.

• https://*.example.com/ совпадает с https://www.example.com/ но не http://www.example.com/.

• *.example.com/ соответствует одновременно https://www.example.com/ и http://www.example.com/.

Если имя хоста в шаблоне маршрута начинается с *, он соответствует хосту и всем его поддоменам. Если имя хоста в шаблоне маршрута начинается с *., он соответствует только всем поддоменам.

• *example.com/ совпадает с https://example.com/ и https://www.example.com/.

• *.example.com/ совпадает с https://www.example.com/ но не https://example.com/.

Следующие примеры иллюстрируют разницу между *example.com/* и *.example.com/*:

Если путь в шаблоне маршрута заканчивается на *, он соответствует всем суффиксам этого пути.

• https://example.com/path* совпадает с https://example.com/path и https://example.com/path2 и https://example.com/path/readme.txt

У всех доменов и поддоменов должен быть DNS-запись проксироваться через Cloudflare и использоваться для вызова Worker. Например, если вы хотите разместить Worker на myname.example.com, и вы добавили example.com в Cloudflare, но ещё не добавили ни одной записи DNS для myname.example.com, любой запрос к myname.example.com приведёт к ошибке ERR_NAME_NOT_RESOLVED.