Type | Name | IPv4 address | Proxy status |
---|---|---|---|
A | proxy-fallback | 192.0.2.1 | Proxied |
Before you start creating custom hostnames:
When you first enable Cloudflare for SaaS, you need to perform a few steps prior to creating any custom hostnames.
The fallback origin is where Cloudflare will route traffic sent to your custom hostnames (must be proxied).
To create your fallback origin:
A
, AAAA
, or CNAME
record pointing to the IP address of your fallback origin (where Cloudflare will send custom hostname traffic).
Type | Name | IPv4 address | Proxy status |
---|---|---|---|
A | proxy-fallback | 192.0.2.1 | Proxied |
Using the hostname of the record you just created, update the fallback origin value.
The CNAME
target — optional, but highly encouraged — provides a friendly and more flexible place for customers to route their traffic. You may want to use a subdomain such as customers.<SAAS_PROVIDER>.com
.
Create a proxied CNAME
that points your CNAME
target to your fallback origin (can be a wildcard such as *.customers.saasprovider.com
).
Type | Name | IPv4 address | Proxy status |
---|---|---|---|
CNAME | .customers | proxy-fallback.saasprovider.com | Proxied |
You need to perform the following steps for each custom hostname.
Before you create a hostname, you need to plan for:
You must complete both these steps for the hostname to work as expected.
After planning for certification and hostname validation, you can create the custom hostname.
To create a custom hostname:
app.customer.com
and set the relevant options, including:
*.<custom-hostname>
SAN to the custom hostname certificate. For more details, refer to Hostname priority.To create a custom hostname using the API, use the Create Custom Hostname endpoint.
certificate_authority
parameter empty to set it to "default CA". With this option, Cloudflare checks the CAA records before requesting the certificates, which helps ensure the certificates can be issued from the CA.For the newly created custom hostname, the POST
response may not return the DCV validation token validation_records
. It is recommended to make a second GET
command (with a delay) to retrieve these details.
The response contains the complete definition of the new custom hostname.
To finish the custom hostname setup, your customer needs to set up a CNAME
record at their authoritative DNS that points to your CNAME
target 1.
Your customer's CNAME
record might look like the following:
This record would route traffic in the following way:
flowchart TD accTitle: How traffic routing works with a CNAME target A[Request to <code>www.mystore.com</code>] --> B[<code>customers.saasprovider.com</code>] B --> C[<code>proxy-fallback.saasprovider.com</code>]
Requests to www.mystore.com
would go to your CNAME
target (customers.saasprovider.com
), which would then route to your fallback origin (proxy-fallback.saasprovider.com
).
If your customer is also using Cloudflare for their domain, they should keep their DNS record pointing to your SaaS provider in place for as long as they want to use your service.
For more details, refer to Remove custom hostnames.
If you have regional services set up for your custom hostnames, Cloudflare always uses the processing region associated with your DNS target record (instead of the processing region of any custom origins).
↩