← Cloudflare for Platforms / cloudflare-for-platforms / workers-for-platforms / configuration

Маршрутизация имён хостов

Вы можете использовать dynamic dispatch Workers для маршрутизации миллионов vanity-доменов или поддоменов на Workers без обращения к традиционным лимиты маршрутов. Такими именами хостов могут быть поддомены в рамках вашего управляемого домена (например, customer1.saas.com) или vanity-доменов, контролируемых вашими конечными клиентами (например, mystore.com), которым можно управлять через пользовательские имена хостов.

Настройте подстановочное Маршрут (*/*) на вашем домене SaaS (домене, где вы настраиваете пользовательские имена хостов), чтобы она указывала на ваш Worker динамической диспетчеризации. Это позволяет вам:

• Поддерживайте и поддомены, и vanity-домены: Обработайте customer1.myplatform.com (поддомен) и shop.customer.com (пользовательское имя хоста) с той же логикой маршрутизации.
• Избегайте лимитов маршрутов: Вместо того чтобы создавать отдельные маршруты для каждого домена, что может привести к достижению Лимиты маршрутов, можно реализовать логику маршрутизации в коде и проксировать миллионы доменов на отдельные Workers.
• Программно управляйте логикой маршрутизации: Напишите собственный код для маршрутизации запросов на основе имени хоста, пользовательские метаданные, путь или любые другие свойства.

Если вы хотите исключить определённые имена хостов из маршрутизации на dispatch Worker, у вас есть два варианта:

• Добавьте маршруты без указания Worker, чтобы исключить определённые имена хоста или пути из обработки dispatcher Worker (например, для saas.com, api.saas.com, и т. д.)
• Используйте выделенный домен (например, customers.saas.com) для управления пользовательским именем хоста и Worker динамической диспетчеризации, чтобы остальной трафик для этого домена оставался отдельным.

Настройка маршрутизации имён хостов с помощью подстановочного маршрута:

1. Настройте пользовательские имена хостов: Настройте свой домен и пользовательские имена хостов с помощью Cloudflare for SaaS
2. Задайте резервный исходный сервер: Настройте резервный исходный сервер, именно сюда будут направляться все пользовательские имена хостов. Если вы хотите направлять их на разные origin-серверы, можно использовать пользовательский исходный сервер. Запросы сначала проходят через Worker и только потом достигают origin-сервера. Если Worker сам является origin-сервером, укажите для резервного исходного сервера фиктивную DNS-запись (например, A 192.0.2.0).
3. Настройте DNS: Направьте DNS-записи (поддомены или пользовательское имя хоста) через Запись CNAME на домен SaaS. Если вашим клиентам нужно проксировать apex-имя хоста (например, example.com) и не можете использовать CNAME-записи, ознакомьтесь с Apex Proxying.
4. Создайте подстановочный маршрут: Добавьте */* маршрут в домене вашей платформы (например, saas.com) и свяжите его со своим dispatch Worker.
5. Реализуйте логику диспетчеризации: Добавьте в свой dispatch Worker логику маршрутизации по имени хоста, которая ищет сопоставления, хранящиеся в Workers KV, или используйте пользовательские метаданные подключённых к пользовательским именам хоста.

export default {
	async fetch(request, env) {
		const hostname = new URL(request.url).hostname;

		// Get custom hostname metadata for routing decisions
		const hostnameData = await env.KV.get(`hostname:${hostname}`, {
			type: "json",
		});

		if (!hostnameData?.workerName) {
			return new Response("Hostname not configured", { status: 404 });
		}

		// Route to the appropriate user Worker
		const userWorker = env.DISPATCHER.get(hostnameData.workerName);
		return await userWorker.fetch(request);
	},
};

Если вам нужно маршрутизировать только записи поддоменов (например, customer1.saas.com), вы можете использовать более точный маршрут (*.saas.com/*) для маршрутизации запросов к вашему Worker динамической диспетчеризации.

Настройка маршрутизации поддоменов:

1. Создайте подстановочную DNS-запись с оранжевым облаком: *.saas.com которая указывает на origin. Если сам Worker является origin, можно использовать произвольное значение DNS (например, A 192.0.2.0).
2. Задайте подстановочный маршрут: *.saas.com/* указывающую на ваш dispatch Worker
3. Добавьте в dispatch Worker логику для маршрутизации запросов по поддоменам к нужному Worker.

export default {
	async fetch(request, env) {
		const url = new URL(request.url);
		const subdomain = url.hostname.split(".")[0];

		// Route based on subdomain
		if (subdomain && subdomain !== "saas") {
			const userWorker = env.DISPATCHER.get(subdomain);
			return await userWorker.fetch(request);
		}

		return new Response("Invalid subdomain", { status: 400 });
	},
};

Если ваши клиенты тоже используют Cloudflare и направляют свой пользовательский домен на вашу зону SaaS через CNAME-запись (например, mystore.com → saas.com), поведение маршрутизации Worker зависит от того, проксируется ли DNS-запись клиента (оранжевое облако) или работает в режиме DNS-only (серое облако). Подробнее об этом читайте в Настройки O2O

Это может привести к непоследовательному поведению при использовании определённых маршрутов имени хоста:

• Если вы маршрутизируете на основе цели CNAME (saas.com), DNS-запись пользовательского имени хоста должна иметь оранжевое облако, чтобы Worker был вызван.
• Если вы маршрутизируете на основе пользовательского имени хоста (mystore.com), запись клиента должна иметь серое облако, чтобы Worker был вызван.

Поскольку вы можете не иметь контроля над настройками DNS-прокси у своего клиента, мы рекомендуем использовать */* подстановочный маршрут, чтобы логика маршрутизации всегда работала предсказуемо, независимо от настройки DNS.

В таблице ниже показано, когда вызываются Workers в зависимости от шаблона маршрута и настроек DNS-прокси клиента: