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. This solution can be helpful with things like these:
- Authorization requests
- Redirects for downloads and for special user agents
- Access-denials and failover settings
- Redirects for special user agents
- Language settings
How it works
Use this behavior to define specific settings so Akamai edge servers can contact your origin server to get your deliverable content.
Before you begin
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.
Select your Origin Type
The options available in this behavior vary, based on what you've selected as your Origin Type.
Origin Type: 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. You can use a NetStorage origin for any static content, including static HTML/JS/CSS, fonts, images and binary files.
Origin Type: Your Origin
You'll select this and use these options if you want to use your own unique origin server to house the original version of the content for delivery. For example, this applies if you host your website on your own web server. Once you've configured these settings, this is where Akamai edge servers will go to get your content.
Origin Server Hostname
Enter the Origin Server Hostname that you established when you set up your origin sever. You should’ve created a new hostname for your origin to use in a DNS record. The DNS record tells edge servers where they need to go to get your content to serve over the Akamai network. See Configure the DNS record for more details.
Origin server hostnames typically use a common naming format such as {origin}-{content-origin} where the following apply:
{origin}. This is what we refer to as the "origin A record." As a best practice, you should use a random string for this value (for example,1hkeh1g76). This serves to conceal your origin server.{content-origin}. If you were serving content from your origin before you onboarded to Akamai, this should be the initial hostname of your origin server, for examplewww.akamaicustomer.com. Otherwise, you can use any valid domain name, as long as the Origin Server Hostname, including the random string, resolves to your origin server through and external DNS.
For example, your origin server hostname that you enter into this behavior field could look like this: 1hkeh1g76-www.akamaicustomer.com.
Variable support
This field supports variable expression syntax. Typing
{{in the option field triggers a list of objects to select. Additional details on this support are available by mousing over this option in the UI. Also see Variables overview.
Forward Host Header
Select which Host header you want your selected 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.
| Option | Description |
|---|---|
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 |
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 |
Custom Value | Select this option if you want to send a custom value in the |
Cache Key Hostname
The cache key is the information your Akamai product uses to identify the content in caches. This assumes 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:
| Option | Description |
|---|---|
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: |
Be careful with new versions of a property
If you have an active property and you create a new version of it that uses a different cache key for all target content, you can create 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.
Origin IP Version
Select the Internet Protocol (IP) version you want to use when getting content from the origin:
- IPv4-Only
- Dual Stack – supports both IPv4 and IPv6 connections.
- IPv6-Only
When using IPv6-Only or Dual Stack, you need to add the Origin IP Access Control List behavior to the same rule or parent rule.
Gzip Compression
Compression can be important in optimizing performance. Verify if it applies to your environment.
Disable this only if your origin server doesn't support delivery of content using Gzip compression, or if you need to serve it uncompressed, but still apply the appropriate Last Mile Acceleration settings. When enabled, Akamai sends an Accept-Encoding: gzip header in requests to your origin server 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, you should 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.
If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. If you want to use TLS version 1.3 in your existing properties, enable this option. New properties have this enabled by default. 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. If you want to use TLS version 1.3 in your existing properties, enable this option. New properties have this enabled by default. 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:
Additional considerations:
Trust Decide what type of certificate or certificate authority the edge server should trust. The process varies depending on your selection:
|
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. If you want to use TLS version 1.3 in your existing properties, enable this option. New properties have this enabled by default. |
Ports
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; 9443; 9901-9908; 11080-11110; 12900-12949; 45002;
Origin TLS Version
This lets you secure the connection between Akamai edge servers and your origin server using transport layer security (TLS).
When an edge server connects to it, your origin server communicates the highest TLS version it supports and attempts the TLS handshake to secure the connection. Any TLS versions that are higher than what your origin server communicates are ignored.
Before you begin
You need to configure your origin server to support the desired level of TLS. Akamai supports TLS versions 1.1, 1.2, and 1.3 for connections to your origin server.
Set options
With the appropriate TLS version enabled on your origin server, set these options:
-
Minimum TLS version. Select the minimum TLS version to use for connections to your origin server. Akamai supported offers support for all versions of TLS that are available to you. This can't be higher than what you've set as the Maximum TLS version. As a best practice, you should configure your environment to use at least TLS 1.3, and select it here.
-
Maximum TLS version. This field is available only if you have this option enabled for your contract. Select the maximum TLS version to use for connections to your origin server. Use Akamai supported to automatically apply the latest supported version. This can't be lower than what you've set as the Minimum TLS version.
Caveats and known issues
Consider these points before setting up this support:
| Issue | Detail |
|---|---|
TLS 1.3 doesn't support renegotiation | Connections using TLS 1.3 don't support renegotiation because it's a potential cyber threat. The renegotiation is just one more point in the transaction that a hacker can exploit. TLS 1.3 introduces a new post-handshake client authentication mechanism. Renegotiation use cases should use this mechanism instead. For more details, see the RFC8446 documentation. |
TLS 1.3 support may not be available if you're using advanced metadata | If you have the Custom Override rule or Advanced behavior in your property and it includes the |
Origin Type: 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 Type: SaaS dynamic origin
If you're a software as a service (SaaS) customer, you'll need to create a SaaS dynamic origin.
Updated 23 days ago