← Cloudflare Workers / workers / configuration / routing

Custom Domains

Custom Domains позволяют подключить Worker к домену или поддомену без изменения настроек DNS и без управления сертификатами. После того как вы настроите Custom Domain для Worker, Cloudflare создаст записи DNS и выпустит необходимые сертификаты от вашего имени. Созданные записи DNS будут указывать непосредственно на ваш Worker. В отличие от Маршруты, Custom Domains направляют все пути домена или поддомена на ваш Worker.

Custom Domains представляют собой маршруты к домену или поддомену (например, example.com или shop.example.com) в зоне Cloudflare, где Worker выступает источником.

Custom Domains рекомендуются, если вы хотите подключить Worker к интернету и у вас нет сервера приложения, с которым нужно постоянно взаимодействовать. Если у вас есть внешние зависимости, вы можете создать Request объект с целевым URI и используйте fetch() чтобы связаться с нами.

Custom Domains можно накладывать друг на друга. Например, если Worker A привязан к app.example.com и Worker B, подключенный к api.example.com, Worker A может вызвать fetch() на api.example.com и вызвать Worker B.

Custom Domains также можно вызывать в пределах той же зоны через fetch(), в отличие от Routes.

Чтобы добавить Custom Domain, у вас должно быть:

1. Одна активная зона Cloudflare.
2. Worker для вызова.

Custom Domains можно привязать к Worker через Cloudflare Dashboard, Wrangler или API.

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

После добавления домена или поддомена Cloudflare создаст для вас новую DNS-запись. Можно добавить несколько Custom Domains.

Чтобы требовать от посетителей входа в систему перед доступом к пользовательскому домену, используйте Cloudflare Access.

Custom Domain можно защитить с помощью Access на основе имени хоста, либо защитить сам Worker для всех его маршрутов, Custom Domains, workers.dev хост и превью. Подробнее см. Cloudflare Access.

Чтобы настроить Custom Domain в вашем конфигурационный файл Wrangler, добавьте custom_domain=true параметр для каждого шаблона в routes. Например, чтобы настроить Custom Domain:

{
	"routes": [
		{
			"pattern": "shop.example.com",
			"custom_domain": true
		}
	]
}

[[routes]]
pattern = "shop.example.com"
custom_domain = true

Чтобы настроить несколько Custom Domain:

{
	"routes": [
		{
			"pattern": "shop.example.com",
			"custom_domain": true
		},
		{
			"pattern": "shop-two.example.com",
			"custom_domain": true
		}
	]
}

[[routes]]
pattern = "shop.example.com"
custom_domain = true

[[routes]]
pattern = "shop-two.example.com"
custom_domain = true

В пределах одной зоны единственный способ для Worker взаимодействовать с другим Worker, работающим на маршрут, либо на workers.dev поддомен, через привязки к сервисам.

Если в пределах одной зоны Worker пытается взаимодействовать с целевым Worker, работающим на Custom Domain, а не на маршруте, это ограничение снимается. Запросы fetch, отправленные в пределах одной зоны от одного Worker к другому Worker, работающему на Custom Domain, будут выполняться успешно без service binding.

Например, рассмотрим следующий сценарий, в котором оба Workers выполняются на example.com зона Cloudflare:

• worker-a работает на маршрут auth.example.com/*.
• worker-b работает на маршрут shop.example.com/*.

Если worker-a отправляет запрос fetch на worker-b, запрос завершится ошибкой из-за ограничения на fetch-запросы в пределах одной зоны. worker-a должен иметь service binding к worker-b для завершения этого запроса.

export default {
	fetch(request) {
		// This will fail
		return fetch("https://shop.example.com");
	},
};

Однако, если worker-b вместо этого был настроен для запуска на Custom Domain shop.example.com, запрос fetch выполнился бы успешно.

Custom Domains не поддерживают подстановочные DNS-записи. Входящий запрос должен точно совпадать с доменом или поддоменом, на который зарегистрирован ваш Custom Domain. Остальные части URL (путь, параметры запроса) при этом сопоставлении не учитываются. Например, если вы создаёте Custom Domain для api.example.com прикреплён к вашему api-gateway Worker, запрос к любому из api.example.com/login или api.example.com/user вызовет тот же api-gateway Worker.

Worker, работающий на Custom Domain, рассматривается как origin. Любые Workers, работающие на маршрутах перед вашим Custom Domain, могут по желанию вызывать Worker, зарегистрированный на вашем Custom Domain, отправив fetch(request) с входящим Request объект. Это означает, что вы можете настроить Workers для выполнения до того, как запрос попадёт в ваш Custom Domain Worker. Другими словами, вы можете связать два Workers в цепочку в рамках одного запроса.

Например, рассмотрим следующий рабочий процесс:

1. Custom Domain для api.example.com указывает на ваш api-worker Worker.
2. Маршрут, добавленный в api.example.com/auth указывает на ваш auth-worker Worker.
3. Запрос к api.example.com/auth запустит ваш auth-worker Worker.
4. Использование fetch(request) в пределах auth-worker Worker вызовет api-worker Worker, как если бы это был обычный сервер приложений.

export default {
	fetch(request) {
		const url = new URL(request.url);
		if (url.searchParams.get("auth") !== "SECRET_TOKEN") {
			return new Response(null, { status: 401 });
		} else {
			// This will invoke `api-worker`
			return fetch(request);
		}
	},
};

Создание пользовательского домена также приведет к созданию Расширенный сертификат для вашей целевой зоны и целевого хоста.

Эти сертификаты создаются с настройками по умолчанию. Чтобы изменить эти настройки, удалите созданный сертификат и создайте собственный сертификат в панели управления Cloudflare. См. Управление расширенными сертификатами с инструкциями.

Поскольку для Custom Domains требуется точное совпадение имени хоста, Worker, привязанный к example.com не будет получать запросы, отправленные на www.example.com, и наоборот. Чтобы обе версии вашего домена работали, настройте правило перенаправления:

• Перенаправление с www на корневой домен
• Перенаправление с корневого домена на www

Также понадобится проксируемая DNS-запись для имени хоста, на который выполняется перенаправление откуда, чтобы Cloudflare мог применить правило перенаправления.

• Для перенаправления с www на корень: добавьте проксируемую DNS A запись для www указывающий на 192.0.2.0, либо проксируемый AAAA запись, указывающую на 100::
• Для перенаправления с корня на www: добавьте проксируемую DNS A запись для вашего корневого домена, указывающую на 192.0.2.0, либо проксируемый AAAA запись, указывающую на 100::

Если сейчас вы вызываете Worker с помощью маршрут с /*, и у вас есть запись CNAME, указывающая на 100:: или подобного, рекомендуемой заменой является Custom Domain.

Чтобы перенести маршрут example.com/*:

Чтобы перенести маршрут example.com/* в вашем конфигурационный файл Wrangler: