Skip to content
Cloudflare Docs
DirectoryAPISDKsChangelog

Regionalized Spectrum Applications

Regionalized Spectrum Applications regionalize HTTP/S traffic using Spectrum, Cloudflare's Layer 4 proxy. Unlike Regional Hostnames — which steer proxied hostnames using Cloudflare's shared anycast IP addresses — a Regionalized Spectrum Application assigns a dedicated IP to your hostname, and that IP signals that all traffic to it must be processed in a specific region.

Choose this option when you need to regionalize traffic that is addressed by IP, or when you need to combine Regional Services with Spectrum Static IPs or Bring Your Own IP (BYOIP).

How it works

You create a Spectrum HTTP/S application for each hostname you want to regionalize. Cloudflare assigns a single processing region to the zone, and that region applies to all Spectrum HTTP/S applications in that zone — you configure one region per zone, not one per application. From then on, traffic to each application's IP terminates TLS and is processed only within the configured region, following the same in-region processing model described in Regional Services.

Prerequisites

  • Spectrum is included in your Enterprise contract. Spectrum is an add-on, so it must be part of your contract before it can be enabled.
  • Your account has the Regional Services and Spectrum entitlements enabled. Contact your account team to enable them.
  • You have a hostname proxied through Cloudflare that you want to regionalize.
  • If you want to use your own addresses, you have onboarded Spectrum Static IPs or a BYOIP prefix.

Set up a Regionalized Spectrum Application

  1. Enable the required products. Work with your account team to enable Regional Services and Spectrum on your account.

  2. Create a Spectrum application for each hostname. Create an HTTP/HTTPS Spectrum application for each hostname you want to regionalize. Set the application type to HTTP/HTTPS so that traffic is routed through Cloudflare's application-layer pipeline. You can create multiple Spectrum applications in a zone; they all share the single region assigned to that zone.

    To use your own addresses, create the application via the API and set edge_ips (with type: "static") to your Static IP or BYOIP addresses. The origin_direct field still points to your origin server.

    Spectrum hostname limits and workarounds

    By default, a zone is limited to 10 unique Spectrum hostnames (each backed by a dedicated IPv4 address). If you need to regionalize more hostnames than this, you can:

    • Use BYOIP — bring your own IP space so Spectrum applications are not constrained by the default shared-IPv4 allocation.
    • Use IPv6-only Spectrum applications — IPv6 addresses are not subject to the same scarcity as IPv4, so IPv6-only applications do not count against the IPv4 hostname limit.
    • CNAME multiple subdomains to a single Spectrum application — point several DNS-only (gray-clouded) CNAME records at one Spectrum app hostname. This works only when those hostnames share the same origin (one origin per application).
    • Use Cloudflare for SaaS — configure the Spectrum application as the target (fallback origin) for Custom Hostnames.

    These are Spectrum-wide limits, not specific to Regional Services. Contact your account team if you expect to exceed them.

  3. Configure the processing region. The region is assigned by Cloudflare, so communicate and work with your account team to confirm which region should apply to your zone and to verify it has been configured. You can use any managed region, or request a custom region if your compliance requirements are not met by the managed regions.

  4. Verify regionalization. Confirm that traffic is processed in the expected region. Refer to Verify the configuration.

Verify the configuration

You can confirm regionalization using the same method as any other Regional Services configuration — refer to Verify Regional Services behavior for the general guidance.

Every Cloudflare HTTP response includes a CF-RAY header that ends with a three-letter IATA airport code ↗ identifying the data center where TLS termination occurred. Send a request to your regionalized hostname and check that the code corresponds to a data center inside your configured region:

Terminal window
curl --head https://www.example.com 2>&1 | grep -i cf-ray
cf-ray: 80cc9e64fd8a1519-MUC

In this example, MUC (Munich) confirms that the request was processed in the European Union. A request sent from outside the region returns a code for an in-region data center, because out-of-region traffic is forwarded to the configured region for processing.

Custom regions

If the managed regions do not match your compliance requirements, you can request a custom region that restricts processing to a specific set of data centers. Custom regions are set up through your account team. To learn more about how custom regions work, refer to the Custom regions blog post ↗.