Origin Server

An origin server is a physical location that houses your deliverable content like a site or app. This is a mandatory behavior and you can't delete this behavior from the Default Rule. An error message is revealed if you delete it, and you need to re-add it. However, you can additionally include the Origin Server behavior in lower-level or nested custom rules, to override the Default Rule in favor of an alternate origin, and set different match criteria to be met to apply this behavior. You might find this solution useful for:

  • authorization requests,
  • redirects for downloads,
  • access-denials, failover settings,
  • redirects for special user agents,
  • language settings, and other.

The origin server is not necessarily your asset. It can also be a directory within a NetStorage storage group. So, available settings in this behavior vary based on the selected Origin Type.

How it works

Use this behavior to define specific settings so ‚ÄčAkamai‚Äč edge servers can contact your origin server to get your deliverable content.

Several types of origin server are supported and there are various prerequisites you need to meet before you can use this behavior to define your origin. What's here is primarily descriptions of the available options. See Add an origin server to your property for complete details on setting up your origin.

Features and options

The options available in this behavior vary, based on what you've selected as your Origin Type.

Origin Server: NetStorage

This is ‚ÄčAkamai‚Äč's secure, cloud-based storage service. It integrates directly with several ‚ÄčAkamai‚Äč delivery products, making it easy to add NetStorage as your origin to your property.

Origin Server: Your Origin

You'll see these options if you're using your own unique origin server to house the original version of the content for delivery. This is where ‚ÄčAkamai‚Äč edge servers go to get you content.

Forward Host Header

In this field, select which Host header you want the ‚ÄčAkamai‚Äč product to pass to your origin server. This is referred to as the Forward Host Header because it is the hostname the product "forwards" to the origin server in the HTTP Host request header.

The web server on your origin uses this value to determine what content to send. Typically, the expected host is the same name as the hostname received in the request from the client, but you can also customize it.

  • Incoming Host Header (Default): When selected, the product sends what you've set as the Hostname in the property hostname to edge hostname association. Typically, it's the end-user-facing hostname for your site or app, and it's used in the connection between the client and ‚ÄčAkamai‚Äč edge servers. This is a generic option that varies depending on the Hostname received in the request. For example, a client request for your website at www.mymedia.com sends www.mymedia.com in the Host header to the origin.

  • Origin Hostname: When selected, the product sends what you've set as your Origin Server Hostname. Select this if you configured your origin to listen for this specific value, The hostname needs to be public or over-internet that resolves to an IP address. You can't use private, internal, or intranet IP addresses (including localhost). For example, assume your origin's hostname is hkeh1g76-www.mymedia.com and this is what you've defined in the Origin Server Hostname field. A client request for your website at www.mymedia.com sends hkeh1g76-www.mymedia.com in the Host header to the origin.

  • Custom Value: Select this option if you want to send a custom value in the Host header to the origin. Define the appropriate value in the Custom Forward Host Header field. This applies if you've configured your origin to listen for a hostname other than what was included in the Host header in the incoming request, or what you set up as its assigned Origin Server Hostname. For example, an end-user request for www.mymedia.com could send www.mymedia.com.akamaized.net in the Host header to the origin.

Cache Key Hostname

The cache key is the information the ‚ÄčAkamai‚Äč product uses to identify the content in caches. Assuming your application includes at least some cacheable content‚ÄĒthe edge network uses keys based on the entire origin URI path and query string, if there is one.

Specify the hostname to use when forming a cache key:

  • Origin Hostname: All objects requested using this origin hostname and the same path and query string are treated as the same object, including the content served from any other configuration with the same origin hostname. For example, once cached, these objects would be treated as the same object:
  • Incoming Host Header (Virtual Server Option): Objects requested with the same path and query string are given a unique cache key by digital property. Select this option if your origin is a virtual server. For example, once cached, these objects would be treated as different objects:


If you have an active property and you create a new property version that has a different cache key for all target content, you can potentially create severe problems for your origin when you activate the new version on production. Any change to the cache key invalidates the cached content using the existing cache key. ‚ÄčAkamai‚Äč edge servers will request new objects from your origin at a level that can create severe spikes in bandwidth.

Gzip Compression

Compression is important in optimizing performance. Verify if it applies to your environment.

Disable this only if your origin server does not support delivery of content using Gzip compression, or if for some reason you want to have content served uncompressed. When this feature is enabled, the product sends an Accept-Encoding: gzipheader in requests to the origin in order to support Gzip compression.


Are you using Ion?

A new Ion property automatically enables Gzip compression via the Minimize Payload sub-rule. If you disable Gzip Compression here, requests will ignore what's set in the Minimize Payload rule. For best performance, we recommend that you leave Gzip Compression enabled.

True Client IP Header

If you enable the Send True Client IP Header option, edge servers pass the original client IP address to the origin.

Normally, the client IP is passed in the X-Forwarded-For header that is routinely modified by proxies along the way. With this option enabled, the default header name True-Client-IP is used unless you set a custom name for the header in the True Client IP Header Name field. Additionally, with the Allow Clients To Set True Client IP Header toggle you can determine if the client name for this header is passed through and accepted, or whether to apply the value you defined in the True Client IP Header Name field instead.

Verification Settings

Use the Origin SSL Certificate Verification options to control how your origin server is authenticated. The verification prevents 'man-in-the-middle' (MITM) attacks, where a malicious entity directs end-user traffic to the attacker's server, instead of your origin.

When an edge server sends a request to your origin, it first establishes a secure connection through an SSL handshake‚ÄĒyour origin provides the ‚ÄčAkamai‚Äč edge server with a certificate for validation. If the validation succeeds, the request goes forward. If the certificate is not valid, the connection fails.


These options don't apply if you've set up your property to deliver via HTTP‚ÄĒyour property hostname uses HTTP and your origin server uses HTTP for transfer, too. Secure (HTTPS) delivery is the industry standard and what ‚ÄčAkamai‚Äč recommends.

Option Details

Platform Settings

Select this if you want to use the settings that the ‚ÄčAkamai‚Äč Secure Network platform applies for Origin SSL certificate verification.

This is the default value for this option that instructs edge servers to trust any certificate signed by the authorities listed in the ‚ÄčAkamai‚Äč Certificate Store. The Common Name (CN) or Subject Alternate Name (SAN) in your origin certificate must also match what you've set in the Forward Host Header field in this behavior.


The platform settings may automatically change at any time.

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header. The use of this certificate type is fully covered in the custom origin (publicly trusted certificate) topic.

Choose Your Own

Select this to control exactly which certificates or certificate authorities ‚ÄčAkamai‚Äč edge servers should trust when connecting with your origin.

This method offers the least vulnerability to man-in-the-middle attacks in case a certificate authority gets compromised. For example, if a common certificate authority is compromised, but you directly provided a certificate, your certificate still remains secure.

With this option selected, several other fields appear.

Use SNI TLS Extension

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header.

Match CN/SAN To

Specify the values ‚ÄčAkamai‚Äč edge servers should look for in your origin certificate's Common Name (CN) or Subject Alternate Name (SAN) fields. When a Subject Alternate Name field is present in the certificate, the Common Name field is ignored. These values are included by default:

  • {{Origin Server}}: The edge server scans either a CN or SAN for the value you've set as the Origin Server Hostname .

  • {{Forward Host Header}}: The edge server scans either a CN or SAN for the value you've set as the Forward Host Header.

Additional considerations:

  • The values you provide can contain an asterisk () character, but it's treated as a literal character and not as a wildcard. For example, if the certificate's CN/SAN value is www.example.com, a match value of `.example.comwill not work. However, wildcards in the certificate's CN/SAN value are still honored. For example, if the CN/SAN value is *.example.com, a match value of either*.example.comorwww.example.com\` will work.

  • The values must include all of the CN/SAN match values from an Auxiliary Certificates List (aux-list), if it exists for your property. If one of these values is missing, a certificate normally trusted from the aux-list may not be trusted and result in a service outage. To include all of these values, import them directly from the aux-list using the Import aux-list button.


Decide what type of certificate or certificate authority the edge server should trust. The process varies depending on your selection:

  • ‚ÄčAkamai‚Äč-managed Certificate Authority Set: Your origin certificate only needs to be trusted by a supported certificate authority (CA). You're not including the specific origin certificate in the property. The sub-options include:

    • ‚ÄčAkamai‚Äč Certificate Store: The CAs tested and known to be trusted for use with ‚ÄčAkamai‚Äč. Click View CA Set to see a complete list.

    • Third Party Certificate Store: The CAs associated with third party origins that are currently trusted for use. Click View CA Set to see a complete list.

  • Custom Certificate Authority Set: Identify the specific CAs that should be used in validation. Click Add Certificate and in the pop-up window select how to apply the certificate authorities:

    • Retrieve for Origin: The edge server retrieves existing certificate authorities from your origin. You need to provide the applicable Hostname / IP for your origin, and the applicable HTTPS Port, typically 443.

    • Paste (PEM-encoded): Paste the PEM-encoded certificate directly into the box provided to add a certificate authority associated with the pasted certificate as a trusted CA. You may need to convert another format into PEM.

  • Specific Certificate (pinning): Use this trust method to "pin" a specific certificate to the property for validation. Either enter your origin's hostname so the edge server can retrieve the specific certificate for you, or paste the PEM-encoded certificate directly into the box provided. You can add multiple certificates, as necessary. See the custom origin (pinned certificate) topic for more details.

  • Satisfies any of the trust options below: This allows you to incorporate both custom CAs, as well as pin specific certificates. If any are sent in the connection, the edge server trusts the origin. Follow the instructions previously listed for each of the corresponding fields.

Third Party Settings

Select this for Verification Settings if you're using a supported third-party origin, such as Amazon AWS. The use of this method is fully covered in the third-party origin topic.

‚ÄčAkamai‚Äč creates a separate certificate authority (CA) set for these third parties, and manages the certificate for you. You don't have to do anything to upgrade your verification settings.

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header.


Specify the ports on your origin server you want edge servers to connect to for HTTP and HTTPS requests, respectively.

The standard ports are 80 for HTTP and 443 for HTTPS.

Acceptable port numbers

72; 80-89; 443; 488; 591; 777; 1080; 1088; 1111; 1443; 2080; 7001; 7070; 7612; 7777; 8000-9001; 9090; 9901-9908; 11080-11110; 12900-12949; 45002;

Origin Server: Media Services Live

This is a unique use case that involves the use of ‚ÄčAkamai‚Äč's Media Services Live product in conjunction with ‚ÄčAkamai‚Äč‚Äč's Adaptive Media Delivery to deliver live streaming media. To incorporate this use case, you'll need to set up your Media Services Live streams and an origin for them first. See the Media Services Live documentation for complete details on this process.

Origin Server: SaaS dynamic origin

If you're a software as a service (SaaS) customer, you'll need to create a SaaS dynamic origin.