StackPath FAQs

The StackPath CDN and WAF automatically include an x-forwarded-for header, for debugging, statistics, and generating location-dependent content, based on the original request.

About X-Forwarded-For

The x-forwarded-for (XFF) header is the default standard header to identify the client IP address for an original request that was served through a proxy or load balancer.

StackPath's x-forwarded-for header will include the IP address the request originated from, followed by the IP address of the StackPath server that proxied the request, and request information from the original Client. Most modules will process IPs right-to-left but can be configured to ignore the StackPath IPs, as will be discussed later.

For Example:

x-forwarded-for: 1.2.3.4, 151.139.81.55 [16/Oct/2018:21:28:36 +0200] freave.nl "GET /js/app.js HTTP/1.1" 200 275854"https://yourdomain.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/1.0.0.100 Safari/1.0"

When the StackPath WAF is enabled, the custom x-sp-forwarded-ip only contains the end-user IP andcan be used in the place of the x-forwarded-for header, for both configurations below.

Apache Module Configuration

The Apache Module mod_remoteip will override the StackPath request IP with the IP provided by a specified header. This will provide the proper client IP address to every service relying on the initial connection.

For most use cases, the RemoteIPTrustedProxyList directive will perform the desired function of taking the real client IP from StackPath's requests when combined with the StackPath IP blocks. This directive will define which request header to use, and then identify a file that contains the list of trusted proxy IPs. Using this directive will apply the list of trusted IPs to all header processing, and will cause Apache to only show the real client IP to other services.

Implementation

Download the text file containing the list of StackPath IPs

Upload that file to your server, or copy the contents to a new text file over SSH

Add the following to either your apache configuration file to globally apply the rules, or just the configuration file for the vhost you have integrated with the CDN:

RemoteIPHeader X-Forwarded-ForRemoteIPTrustedProxyList conf/StackPath-ipblocks.txt

Remember to replace conf/trusted-proxies.list with the actual file path to the list of StackPath IPs.

You can learn more from the official Apache documentation regarding the mod_remoteipmodule.

Nginx Module Configuration

The ngx_https_module module can be used to change the client address based on a specified header field. This module is not enabled by default and should be enabled with the --with-http_realip_module configuration parameter.

Implementation

With the module enabled, applying the real IP for Nginx is as simple as adding the following text to your configuration file, and including a set_real_ip_from line for each of StackPath's IP ranges:

#list of trusted IPs

...

set_real_ip_from 209.197.8.0/21;

set_real_ip_from 209.197.21.0/24;

set_real_ip_from 209.197.24.0/21;

set_real_ip_from 209.234.242.0/25;

#To ignore the trusted IPs, and only use IPs not present on the list

real_ip_recursive on;

#To specify the header to use for the module

real_ip_header x-forwarded-for;

Doing this will allow Nginx to use the real client IP included with the x-forwarded-for header in place of any of the StackPath IPs. You can learn more from the official Nginx documentation for this module.

If you have any questions or experience any issues, please reach out to the support, live chat and ticket support are available 24/7.

The billing information for your account can be updated at any time from within your account.This guide will walk you through how to add or update your billing information.

Adding or Updating Billing Information

You can add or update billing information at any time when it has not been added by:

Login to your StackPath account Credit Cards and PayPal accounts

Select Billing from the Profile drop-down in the top right corner

Select Update Information, and fill out the form provided

Remember toSave Changes

Add your desired Payment Method, StackPath currently supports

For security reasons, web browsers will prevent JavaScript code from making requests to a different domain (also known as the origin) than the one it's hosted on. Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin.

Misconfigured CORS

Misconfigured CORS Headers can lead to missing fonts or broken JavaScript assets. These usually manifest themselves by missing asset icons in place of stylesheets, fonts, or actual icons.

https://c7s7y6z8.stackpathcdn.com/wp-content/themes/landing/font1.ttf

This can be caused by one of threeissues:

Missing CORS headers - where the browser is denying permission to view these contents because there is no Cross-Origin Resource Sharing header.

Double CORS headers - where the browser is only expecting one value for the CORS header but is receiving two.

Restrictive CORS Policy - where the browser expects only one domain to have access to the content and a different domain is trying to access it.

Troubleshooting CORS Headers

Troubleshooting CORS headers is easy and requires no special tools. It can even be done within your web browser, just follow these steps:

Right-clickorCommand-Click(for Mac) anywhere on your web page.

Select theInspectorInspect Elementoption to pull up your browser's developer tools.

Select theConsoleoption.

Double CORS

Double CORS errors occur when your origin server and StackPath are both setting an access-control-allow-origin header for your content. Browsers only expect one value for access-control-allow-origin and will deny access in the presence of both headers. When double CORS issues are present a message in the browser debug console will look something like this:

Access to Font at ' http://c7s7y6z8.stackpathcdn.com/wp-content/themes/landing/font1.ttf ' from origin 'http://example.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed. Origin 'http://example.com' is therefore not allowed access.

You can also see this issue by looking at the Response Headers, since theAccess-Control-Allow-Originheader will appear twice.

This can be rectified by disabling the CORS Header Support setting in the StackPath Control Panel to return the CORS header to one value generated by your origin server. You can find this under 'Sites> Your Domain > CDN > Client Browser Policy':

Missing CORS

Missing CORS errors occur when there is no access-control-allow-origin header present in responses from separate domains than your root page source. When this header is missing, the browser debug console will display a message similar to this:

Access to Font at ' https://c7s7y6z8.stackpathcdn.com/wp-content/themes/landing/font1.ttf ' from origin 'http://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://example.com' is therefore not allowed access.

This can be corrected by Enabling theCORS Header Supportsetting in the StackPath Control Panel. The default "All Origins" value for Access-Control-Allow-Origin allows for any domain to have access to this content.

Once added, you will see anAccess-control-Allow-Originheader appear in the response headers of content delivered from the CDN.

For Extra Security, you can specify a domain instead of using the wildcard (*) to only allow the specified domains. Using the wildcard will allow every domain to have access to the content while specifying a domain will allow only the specified domain to have access. In this example, onlyhttps://google.comis allowed. To edit your Access-Control-Allow-Origin header, change the "Allowed Origins" dropdown box to "Specified Origins",enter the specified origin and then click 'Save':

This will add your specified domain to theAccess-Control-Allow-Originresponse header from content served from the StackPath CDN.

Restrictive CORS

Restrictive CORS errors occur when the value of the access-control-allow-origin header included with a response does not match the actual domain returning the content. When this happens, the browser debug console will display a message similar to this:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at'' from origin 'https://foo.bar'(Reason: CORS header Access-Control-Allow-Origin does not match example.com')

This can be alleviated by either switching the content of the Access-Control-Allow-Origin header to "All Origins" or to the specific URL that is attempting to gain access to the content, in the above example, this would be https://foo.bar.

How am I Billed for Object Storage

Object Storage billing is designed to be straightforward and easy to understand. Billing for the service is at an effective rate of approximately $.01/GB per month (though in months with -+ 30 days it's slightly different).

More precisely, we query storage totals per day @$.000333334 per GB.

Let's look at an example to see how this benefits you. Charging you per day allows you to only be charged for the days you actually started using data.

If you upload 100GB on a certain day, you will be billed usage on 100GB on that day and every day after that until that data is deleted (more on this further ahead).

An Example: Let's say your bill day is the first of the month, but you only uploaded 100GB on the 27th. Instead of billing you $1.00 for 100GB of storage, we collect usage daily, so you're only charged for 4 days of usage in this case.

https://control.stackpath.com

For this example above, you would be billed for 400GB * $.000333334 = $0.13

We decided it was fairer to bill per day rather than "per month". This way, you only get billed for days you actually have storage.

To arrive at our daily charge rate for storage, we took $.01/GB and divided it by 30 days (and rounded it to the nearest 1 billionth of a penny). That's how we arrive at the $.000333334 amount.

What if I Delete/Add Files?

Adding Files

Object Storage, as we've shown above, is charged on usage summed on a per-day basis, and new files added will begin to get billed against your storage usage starting with the day you upload it.

Example:(Dates used are for illustrative purposes only)

If you are being billed for 100GB of current usage on June 1st, and then add an additional 100GB on the 8th - the usage of 200GB will begin on June 8th.

Here's what that looks like:

Deleting Files

Files that have been uploaded have a minimum storage life of 30 days. Any file deleted before 30 days will remain and will be tracked as "deleted" storage. If you delete a file you uploaded 15 days ago, it will continue to be billable for an additional 15 days. After day 30, it is immediately no longer tracked as billable storage.

Example: (Dates used are for illustrative purposes only)

If you upload 100GB of files on January 1st and delete 20GB of those files, your usage will continue to be billed as 100GB until January 30th. Starting January 31st, your total is now at 80GB.

After 30 Days, space used by the deleted files will no longer be billed.

Deleting a Bucket

The 30-day rule is still in effect, even if the entire bucket is deleted. After the 30 days, you are no longer billed for storage in a deleted bucket. if All the files in the bucket were at least 30 days old at the time the bucket was deleted, billable usage will stop immediately.

How can I See My Current Usage?

Current Usage for any Object Storage bucket can be found in theSpace Usage graph when viewing that bucket

The Blue line represents currently used storage

This is storage currently being used by your files

Does NOT include deleted files

The Red line represents deleted storage - This shows the amount of storage being used by deleted files

The size of this number shows deleted files that are still in your bucket after having been deleted

These files are permanently removed after 30 Days, after which billing for that space stops

It is not recommended to delete a bucket until you see that the total storage amount is 0GB. That way, you can easily reference the graphs in the portal to see what your daily storage totals are.

If you have any questions regarding this article, contact us 24x7 at [email protected] or via 24x7 live chat through .

It is easy to monitor the ingress and egress bandwidth of any Workload through the StackPath API. Below will explain the simple API Endpoint to collect Compute bandwidth data for periodic collection or one-off analysis.

Metrics Explained

Bandwidth metrics can be pulled for an entire stack or for an individual workload. Bandwidth is always divided by StackPath PoP locations and will have to be summed for total use.

Endpoint: https://gateway.stackpath.com/workload/v1/stacks/<stack_id>/metrics

Method: GET

Query Parameters

type (String) (Required) Set the value as "BANDWIDTH" to pull bandwidth metrics

start_date (Datetime) (Required)Start Date specified the beginning of the reporting period over which the call pulls metrics from. If this period is before the date of workload creation, all values will be set to zero. The datetime string should be in the standard datetime format YYYY-MM-DDTHH:MM:ss.sssZ

end_date (Datetime) (Required)End Date specified the end of the reporting period over which the call pulls metrics from. If this period is after the current time, a JSON response with 'message': 'Unable to get metrics at this time'. will be returned. The datetime string should be in the standard datetime format YYYY-MM-DDTHH:MM:ss.sssZ workload_id (String) (Optional, Default: All Workloads) Workload ID can be pulled from the URL in the StackPath Control Panel or from the Compute API GET workloads endpoint.

granularity(String) (Optional, Default: PT5M)

The summation period of metrics between the start_date and end_date.

PT5M - 5 minutes

PT1H - 1 hour

P1D - 1 Day

PoP (String) (Optional, Default: ALL)Filter traffic metrics by StackPath Point of Presence. Pull the possible location identifiers via the StackPath API Endpoint GET Locations.

Daily Metrics by Workload

API Request

Method: GET Endpoint: https://gateway.stackpath.com/workload/v1/stacks/{stack_id}/metrics

Payload

{ 'start_date': '2019-03-23T14:54:18.442Z', 'end_date': '2019-03-24T14:54:18.442Z', 'wordload_id': "{stack_id}", 'type': "BANDWIDTH", 'granularity': 'P1D', }

cURL Example

curl "https://gateway.stackpath.com/workload/v1/stacks/<stack_id>/metrics?start_date=2019-03-23T14:54:18.442Z&end_date=2019-03-24T14:54:18.442Z&workload_id=<workload_id>&type=BANDWIDTH&granularity=P1D" -H "Authorization: Bearer <token>"

Hourly Metrics by Instance

API Request

Method: GET Endpoint: https://gateway.stackpath.com/workload/v1/stacks/{stack_id}/metrics

Payload

{ 'start_date': '2019-03-23T14:54:18.442Z', 'end_date': '2019-03-24T14:54:18.442Z', 'workload_id': "{stack_id}", 'instance_name': "{instance_hostname}" 'type': "BANDWIDTH", 'granularity': 'PT1H', }

cURL Example

curl "https://gateway.stackpath.com/workload/v1/stacks/<stack_id>/metrics?start_date=2019-03-23T14:54:18.442Z&end_date=2019-03-24T14:54:18.442Z&workload_id=<workload_id>&instance_name=<instance_hostname>&type=BANDWIDTH&granularity=PT1H" -H "Authorization: Bearer <token>"

Filtered metrics by PoP

API Request

Method: GET

Endpoint: https://gateway.stackpath.com/workload/v1/stacks/{stack_id}/metrics

Payload

{ 'start_date': '2019-03-23T14:54:18.442Z', 'end_date': '2019-03-24T14:54:18.442Z', 'workload_id': "{stack_id}", 'type': "BANDWIDTH", 'granularity': 'P1D', 'pop': 'lhr02' }

cURL Example

curl "https://gateway.stackpath.com/workload/v1/stacks/<stack_id>/metrics?start_date=2019-03-23T14:54:18.442Z&end_date=2019-03-24T14:54:18.442Z&workload_id=<workload_id>&type=BANDWIDTH&granularity=P1D&pop=lhr02" -H "Authorization: Bearer <token>"

API Response

Status Code: 200

{ "status":"success", "data":{ "resultType":"matrix", "result":[{ "metric":{ "__name__":"ingress_bandwidth", "pop":"lhr02", "traffic_region":"INTERNET"}, "values":[[1553385600,"2569901"]]},{ "metric":{ "__name__":"egress_bandwidth", "pop":"lhr02", "traffic_region":"INTERNET"}, "values":[[1553385600,"4442578"]] } ]}}

Each polling time period contains two types of results, ingress and egress. Ingress measures the inbound traffic to the compute instance, while egress measures outbound traffic from your instance. For each traffic region, the values list contains an epoch timestamp and the total amount of data in bytes. Examining the response above, the epoch time "1553385600" translates to Sunday, March 24, 2019 12:00:00 AM and the public ingress of "2569901" bytes converts to 2.6MB.

If you have any additional questions or concerns, feel free to reach out to StackPath Support via [email protected] or over our 24/7 live chat.

When you configure your service monitoring, you can choose which locations check requests are issued from.

Available locations are listed below:

Albania, Tirana

Provider: Albanian Hosting

API ID: tia ( docs )

192.166.245.71

192.166.245.98

Australia, Sydney

Provider: Google Cloud Platform

API ID: syd ( docs )

35.201.16.129

35.244.107.67

Australia, Sydney

Provider: Vultr

API ID: syd-vul ( docs )

108.61.185.90

104.156.232.232

IPv6

2001:19f0:5800:8bfc:5400:ff:fe1c:5b87

2001:19f0:5800:8d34:5400:ff:fe1c:5b8c

Brazil, Sao Paulo

Provider: Google Cloud Platform

API ID: spa ( docs )

35.198.52.85

35.198.12.22

Chile, Vina del Mar

Provider: EDIS GmbH

API ID: vdl-edi ( docs )

37.235.52.70

37.235.52.196

IPv6

2a03:f80:56:37:235:52:70:1

2a03:f80:56:37:235:52:196:1

China, Hangzhou (Shanghai)

Provider: China VPS Hosting

API ID: sha-cvh ( docs )

120.26.119.191

47.97.251.164

France, Paris

Provider: EDIS GmbH

API ID: par-edi ( docs )

151.236.21.35

151.236.21.87

IPv6

2a01:348:99:151:236:21:35:1

2a01:348:99:151:236:21:87:1

Germany, Frankfurt

Provider: EDIS GmbH

API ID: fra-edi ( docs )

149.154.159.21

151.236.15.26

IPv6

2a03:f80:49:149:154:159:21:1

2a03:f80:49:151:236:15:26:1

Germany, Frankfurt

Provider: Google Cloud Platform

API ID: fra-amz ( docs )

35.242.213.204

35.242.210.32

Hong Kong, Hong Kong

Provider: EDIS GmbH

API ID: hkg-edi ( docs )

158.255.208.86

151.236.20.95

IPv6

2a03:f80:852:158:255:208:86:1

2a03:f80:852:151:236:20:95:1

Iceland, Reykjavik

Provider: EDIS GmbH

API ID: ice-edi ( docs )

151.236.24.35

151.236.24.50

IPv6

2a03:f80:354:151:236:24:35:1

2a03:f80:354:151:236:24:50:1

Ireland, Dublin

Provider: Amazon

API ID: dub ( docs )

34.249.164.113

54.76.234.169

Italy, Milan

Provider: EDIS GmbH

API ID: mil-edi ( docs )

149.154.157.239

151.236.18.167

IPv6

2001:b60:1000:149:154:157:239:1

2001:b60:1000:151:236:18:167:1

Japan, Osaka

Provider: Azure

API ID: osa-azr ( docs )

104.214.150.207

104.214.147.166

Japan, Tokyo

Provider: Google Cloud Platform

API ID: tyo ( docs )

34.85.22.40

35.200.117.161

Japan, Tokyo

Provider: Vultr

API ID: tyo-vul ( docs )

45.32.45.117

45.32.52.15

IPv6

2001:19f0:7000:9aa1:5400:ff:fe1c:1090

2001:19f0:7000:9c35:5400:ff:fe1c:4562

New Zealand, Auckland

Provider: VPSNine

API ID: akl-zap ( docs )

103.209.192.93

45.252.191.10

Russia, Moscow

Provider: EDIS GmbH

API ID: msk-edi ( docs )

213.183.56.71

213.183.56.187

IPv6

2a03:f80:7:213:183:56:71:1

2a03:f80:7:213:183:56:187:1

Singapore, Singapore

Provider: Google Cloud Platform

API ID: sng ( docs )

35.186.155.99

34.87.56.240

South Africa, Johannesburg

Provider: Azure

API ID: jhb-elh ( docs )

102.133.165.127

102.133.168.247

Spain, Madrid

Provider: EDIS GmbH

API ID: mad-edi ( docs )

151.236.23.78

151.236.23.142

IPv6

2a00:1d70:ed15:151:236:23:78:1

2a00:1d70:ed15:151:236:23:142:1

Sweden, Stockholm

Provider: EDIS GmbH

API ID: sto-edi ( docs )

46.246.93.179

46.246.126.136

IPv6

2a00:1a28:1251:46:246:93:179:1

2a00:1a28:1251:46:246:126:136:1

The Netherlands, Amsterdam

Provider: Google Cloud Platform

API ID: ams-pla ( docs )

34.90.24.209

35.204.22.69

The Netherlands, Amsterdam

Provider: EDIS GmbH

API ID: ams-edi ( docs )

151.236.14.231

151.236.14.238

IPv6

2a00:1768:1003:151:236:14:231:1

2a00:1768:1003:151:236:14:238:1

UK, London

Provider: Rackspace

API ID: lon ( docs )

95.138.170.88

95.138.175.4

IPv6

2a00:1a48:7805:113:be76:4eff:fe08:25fa

2a00:1a48:7805:113:be76:4eff:fe09:1f07

UK, London

Provider: Vultr

API ID: lon-vul ( docs )

45.32.183.237

45.32.179.191

IPv6

2001:19f0:7401:834f:5400:ff:fe1c:c96

2001:19f0:7401:844e:5400:ff:fe1c:c99

UK, Manchester

Provider: LoveServers

API ID: man-lov ( docs )

185.157.232.52

185.157.233.153

IPv6

2a07:4580:b0d:f::6324

2a07:4580:b0d:82::793a

USA, Chicago

Provider: Rackspace

API ID: chi ( docs )

23.253.20.207

23.253.22.201

IPv6

2001:4801:7824:101:be76:4eff:fe10:55c6

2001:4801:7824:101:be76:4eff:fe10:24dc

USA, Dallas

Provider: Vultr

API ID: dal-srv ( docs )

207.148.1.50

149.28.254.195

USA, Los Angeles

Provider: Vultr

API ID: lax-vul ( docs )

45.32.69.31

45.32.94.5

IPv6

2001:19f0:6000:9301:5400:00ff:fe1c:0085

2001:19f0:6000:95c5:5400:ff:fe1c:88

USA, New York

Provider: Vultr

API ID: nyc-ovi ( docs )

149.28.235.77

63.209.33.45

USA, North California

Provider: Amazon

API ID: nca ( docs )

52.52.23.91

52.53.106.71

USA, North Virginia

Provider: Amazon

API ID: vir ( docs )

34.201.233.220

34.203.52.30

USA, San Jose

Provider: Vultr

API ID: sjc-pla ( docs )

45.32.129.60

45.63.90.144

USA, Seattle

Provider: Vultr

API ID: sea-vul ( docs )

104.238.157.42

45.32.225.132

IPv6

2001:19f0:8000:8652:5400:ff:fe1c:45c2

2001:19f0:8000:8706:5400:ff:fe1c:45c4

USA, Washington

Provider: Google Cloud Platform

API ID: iad ( docs )

35.245.111.92

35.245.0.188

Ukraine, Kiev

Provider: WDMSH

API ID: iev ( docs )

78.142.19.197

84.54.49.15

To reduce any false-positives you should whitelist these IP addresses in your firewall/network. Use the following command to retrieve and extract the IP addresses as a single list:

curl -silent https://support.stackpath.com/hc/en-us/articles/360001332103 | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'

Whitelisting StackPath's IP blocks ensures StackPath edge servers can pull data from your origin server. Needing to whitelist StackPath's IP's in firewalls and security systems is the most common reason behind 502 errors.

This article will show you how to use the StackPath API to pull the most up to date IP block list at any time. You can use this guide to apply these IPs to the whitelist on your origin.

This guide assumes you have already taken the steps to set up API Access for your StackPath account. StackPath RESTful API calls can be made either directly through a terminal with curl, or your favorite API REST client.

Step 1: Get an Auth Token

This request also requires obtaining an authorization prior to making the call. These tokens expire every hour, so this process will likely need to be repeated with every use of these API Calls. To obtain your authorization token, generate a POST request towardhttps://gateway.stackpath.com/identity/v1/oauth2/token with the body that contains the following information:

{ "client_id": "client_id", "client_secret": "client_secret", "grant_type": "client_credentials"}

Remember to replace client_id and client_secret with your actual client id and the sercret key generated when setting up API access

This should produce a response with the following JSON object:

{ "access_token":"this_is_your_token_and_its_around_700_characters", "token_type":"bearer", "expires_in":3600 }

This contains your 700 character Authorization token that will be used to validate the request later in this session.

Step 2: Request the CDN and WAF IP List

The CDN and WAF IP blocks can be pulled with a GET request towardhttps://gateway.stackpath.com/cdn/v1/ips that contain the following header: Authorization: Bearer <your_access_token>

This should produce a response with the following JSON object, that contains all of the IPs used by the CDN and WAF to pull content from your origin(truncated) :

{ "results": [ "2a0a:e200:1a00::/40", "2a0a:e200:1c00::/40", "2a0a:e200:1100:1100::/64", "2a0a:e200:1100::/40", "2a0a:e200:1200:1100::/64", "2a0a:e200:1200::/40", "2a0a:e200:1300::/40", "2a0a:e200:1400::/40", "2a0a:e200:1500::/40",.... ]}

You can also adjust the scope for this pull by attached the following queries to the request in order to obtain the information in a format other than JSON, or to separate out the IPV4 and IPV6 addresses using the following:

https://gateway.stackpath.com/cdn/v1/ips?response_type=PLAIN_TEXT- to force the output to plain text format instead of JSON. https://gateway.stackpath.com/cdn/v1/ips?filter=IPV4- to specify only IPV4 addresses https://gateway.stackpath.com/cdn/v1/ips?filter=IPV6- to specify only IPV6 addresses

Step 3: Request the Monitoring service IPs

When Monitoring is enabled for your stack, the Monitoring service IP address can be pulled with a GET request to https://gateway.stackpath.com/monitoring/v1/stacks/<stack_id>/locations. This will also need to be sent with the following header: Authorization: Bearer <your_access_token> Remember to replace <stack_id> with your actual Stack ID, this can be found here. This call should produce a JSON object that lists out every location used by our monitoring service, with information about each location, including the field "ipAdresses" that contains the IP address used to make requests toward your origin.

This will be the in the following format:

...{ "id": "dal-srv", "name": "USA: Dallas", "city": "Dallas", "country": "USA", "provider": "StackPath", "ipAddresses": [ "209.107.216.205", "209.107.216.206" ] }, { "id": "lax-vul", "name": "USA: Los Angeles", "city": "Los Angeles", "country": "USA", "provider": "Vultr", "ipAddresses": [ "45.32.69.31", "45.32.94.5", "2001:19f0:6000:9301:5400:ff:fe1c:85", "2001:19f0:6000:95c5:5400:ff:fe1c:88" ] },...

You can also call just the locations used by your monitor by making a GET request to https://gateway.stackpath.com/monitoring/v1/stacks/<stack_id>/http_monitors. Remember to include the Authorization header: Authorization: Bearer <your_access_token> Remember to replace <stack_id> with your actual Stack ID, this can be found here. This call will return all the information about each monitor in use on your stack, with an included JSON object called "locations" that contains similar formatting as the previous call, but will only include the monitoring locations enabled for your specific monitor:

"results": [ { "id": "eaf2ffa0-2afb-4351-a344-937bc471bba8", "remoteId": "5b393a24b03e85ff038b456b", "name": "Testing", "url": "https://www.stackpath.com", "currentStatus": "slow", "uptime": 1, "avgResponseTime": 0.37663442459657215, "method": "GET", "timeout": 10, "ipVersion": "IPV4", "locations": [ { "id": "fra-edi", "name": "Germany: Frankfurt", "city": "Frankfurt", "country": "Germany", "provider": "EDIS GmbH", "ipAddresses": [ "149.154.159.21", "151.236.15.26", "2a03:f80:49:149:154:159:21:1", "2a03:f80:49:151:236:15:26:1" ] },...

An Origin is where StackPath services retrieve all content for delivery. When content is requested by end-users, but not present in the CDN's Cache (aka a cache-miss), StackPath will need to know where your content is located, and how to fetch it.

If you would like to configure a cloud storage bucket for your origin, please review these articles tailored to specific bucket providers: Google Cloud Storage Amazon S3

Control Panel Settings

A Site's Origin can be configured by selectingSites>> The Domain you'd like to configure >>theSettings tab

control panel

Origin Address

The Origin Address can be input in one of two ways:

Direct IP: Change the IP in the Origin Address box on StackPath Control Panel. This lets StackPath pull directly from your server. In this case, you will need to update the settings if you ever migrate to a separate hosting provider.

Domain: This makes StackPath resolve your server IP through DNS for any Origin Pull. In this case, you will not need to update the settings when migrating to a separate hosting provider. (If you have pointed your domain to the StackPath Anycast IP, or Edge Address for your website, using a domain in the Origin Address Field may generate errors)

Origin Backup

StackPath allows for the use of a backup origin by enabling this setting. You can input another address to be used in the event the default address returns a 400 or 500 class error. Feel free to read this article about Backup origins, if you'd like to know more information.

Origin Host Header

This is used as the "Host" Request HeaderStackPath sends to your origin upon content pull. This setting will need to be set to the version of your URL your website will respond to. If this is misconfigured in any way, StackPath may have trouble finding your content. The default list is taken from Delivery Domains you have configured, but a custom header is always configurable.

Origin Pull Protocol

The Origin Pull Protocol is the protocol StackPath will use when contacting the Origin. This setting has three options:

HTTP or HTTPS: StackPath will make a request to the Origin with the protocol that was specified by the end-user. This is ideal if there is an HTTP to HTTPS redirect enabled on the origin and you would like StackPath's services to follow that.

HTTP Only: StackPath will make requests to the origin over the non-secure HTTP port 80. This is useful if there is no SSL certificate configured on the Origin, and can be used to securely deliver content to end-users.

HTTPS Only: StackPath will make requests to the origin only over the secure HTTPS port 443. This is useful for origins with SSL configured, but no redirect is in place. This is also the recommended setting for using StackPath's "Force HTTPS" EdgeRule.

Configuring these settings will allow StackPath to appropriately pull content from the desired origin.

Using the StackPath API

The following will guide you step-by-step on how to changea single origin through the API. If you have not used the StackPath API yet, read this introduction here to get started.

Step 1: Get your Stack ID

After logging into the and viewing a Stack, the ID is at the end of the URL, which looks like this.

https://control.stackpath.com/stacks/<this-is-your-stack-id>

Step 2: Retrieve a list of Origins

After documenting the stack ID, retrieve a list of Origin IDs that will be needed to update with the Origin IP. All Origin IDs will be listed for the account, so be sure to parse through them to determine which Origin is desired.

curl -H "Authorization: Bearer <token>" -H "Content-type: application/json" "https://gateway.stackpath.com/cdn/v1/stacks/<origin_id>/origins"

Step 3: Update Origin Hostname

This final step will push changes to the Zone configurations. Once submitted, StackPath will immediately redirect Origin pulls to the new IP address or hostname.

If you're not sure what you should set for Path, set it to your website root '/'.

The hostname should not include the protocol (HTTP, HTTPS)

Port is your HTTP port, not required. Set to 80 or custom port

SecurePort is your HTTPS port and is not required. Set to 443 or custom port.

curl -H "Content-Type: application/json" -H 'authorization: Bearer <token>' -X PATCH https://gateway.stackpath.com/cdn/v1/stacks/<stack_id>/origins/<origin_id> -d '{"path": "string", "hostname": "string", "port": int, "securePort": int}'

General CDN Solution for OpenCart is a paid web extension that helps web administrators manage content caching inside the OpenCart CMS.

This article will walk you through the most simple Static Assets Integration. To get the most out of StackPath (WAF and DDoS protection) you will need to use a Full Site Integration

Before you begin, it is highly recommended that you test the performance of your site using Google Page Speed or Pingdom Tools. You can test your site now and after setting up the plugin for a before and after performance comparison.This tutorial assumes you've already gone through the steps to create a StackPath Site.

Installation

1.Downloadthe General CDN Solution extension

2. Login into your OpenCart admin panel

2.1 Go to Extensions -> Installer StackPath SSL Options

2.2 Upload your General CDN Solution extension

3. Go to Extensions -> Extensions and under modulesfind Opencart CDNand click on Install(+)

4. Once installed, SelectEdit

4.1 Set status for General and CDN for SSL to Enabled

4.2 Add your Edge Addressor custom Delivery Domain to the custom domain in theme resources.

4.3 Check Yesfor CDN Delivers Images, CDN Delivers JS and CDN Delivers CSS

4.4 Save your settings

5. Under Extensions -> Modifications and in the right top corner click on the refresh button

After following these steps you will have successfully integrated CDN in your OpenCart CMS.

Test Speed and SEO After Integration

To ensure you implemented the StackPath CDN correctly, you can view the source code of any page to confirm that the CDN domain is being used for static assets instead of your origin domain. You can also use tools like Pingdom to obtain a more detailed report on your CDN implementation status.

What's Next?

Feel free to take a look at these articles for some possible next steps with your CDN Integration:

CDN Configuration Settings Explained

CORS Header Configuration

If you have any questions or concerns,our 24/7 live support would be happy to help!

The StackPath CDN is compatible with Amazon S3 Buckets as origin Pulls. This may require you setting the Bucket access permissions through Bucket Policy or Access Control List to allow the CDN to obtain access. This article will walk you through the setup process.

Setting up Bucket Access

For this example, the bucket was set up to allow public read-only access, so that anyone can view the contents of the bucket. This will require no preconfigured Public Access settings for your account:

SelectAccess Control Listfrom thePermissions tab for the bucket Use Scenarios

SelectEveryoneand enableList Objects to grant public access to only view objects

You can read more about Amazon AWS permissions and policies here, to configure the bucket access differently, to allow only select access by using examples found here, and our IP list found here.

Setting Up the CDN

This example uses a bucket named stackpathtesting within the us-east-2 region, please replace any instance of stackpathtesting or <bucketname> with the actual name of your bucket and any instance of us-east-2 or <aws-region> with the actual region for your bucket.

Log in to StackPath

Create a new Site

Enter the Domain Name for the site being created.

Set the Bucket URL to s3.<aws-region>.amazonaws.com/<bucketname>. Set Origin Authentication if the bucket has been configured as such, or leave None if no authentication is required.

View the newly created Site and select theSettings tab to confirm theHost Header

Now, confirm the Host Header is set ass3.<aws-region>.amazonaws.com if you used s3.<aws-region>.amazonaws.com/<bucketname>.

Test the Edge Address by visiting it with the browser. This should produce an XML File that contains an index of all of the objects within the bucket. Once this is confirmed, you can now serve your bucket objects over the CDN Cache using http://cdn.url/path/to/bucket/object (And replacing cdn.url with the Edge Address was generated upon creating the Site)

Next Steps

Connecting the StackPath CDN can be useful for

Using your S3 bucket as a static website, and serving it over the CDN

Using the CDN to serve any of Amazon's suggested

The 502 Bad Gateway Error means that our network is unable to communicate with your server. This tutorial will show you how to troubleshoot this unwanted response.

As a part of a DDoS mitigation process, or as a result of some strict firewall rules, our servers can be blocked from accessing the origin web server. In this case, you just need to whitelist our IP blocks in y our firewall rules. Also, it is worth mentioning that some security plugins (for the CMS you use if you use any) for DDoS mitigation may act the same as a firewall that is blocking us.

Below we show the typical traffic pattern that typically results in a 502 Bad Gateway error.

If the problem persists, please feel free to start a live chat or submit a ticket with support.

Sometimes, an SSL provider (Certification Authority) will revoke a certain SSL certificate from the chain of trust, but the certificate will remain in local cache. This will produce error messages, like "Certificate Revoked" or similar.

When that occurs, clearing the local CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) caches will force an operating system to fetch the new intermediate SSL certificate and restore the chain of trust when performing SSL handshake.

Clearing local CRL and OCSP cache on Microsoft Windows (7 or newer)

Open the Command Prompt or PowerShell and type the following:certutil -urlcache * delete

To only deletethe CRLcache:certutil -urlcache crl delete

Clearing local CRL and OCSP cache on Apple OS X (10.6 or newer)

Open the Terminal.app application and type the following

sudo rm /var/db/crls/*cache.db

(You will be prompted to enter your administrator password)

Clearing local CRL and OCSP cache on Apple macOS Sierra (10.12)

Open the Terminal.app application and type the following:

sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM responses WHERE responderURI LIKE "%http://%.globalsign.com/%;'

Occasionally, users are presented with 5XX errors when implementing the StackPath Services with an Origin server. This article will help guide through some of the common issues.

Examples of 5xx Response Codes?

500-class response codes indicate a server failure occurred while processing a request. When using a CDN, it's helpful to think of them like this:

502 - Bad Gateway: The edge server(CDN), when acting as a proxy received an invalid response from the origin server. (Also referred to as the upstream server)

Imagine the request as a phone call - Someone picked up the phone, but it wasn't who you expected.

504 - Gateway Timeout:The edge server(CDN), when acting as a proxy did not receive a timely response from the origin server.

Imagine the same phone call, but it never even rings. It just says 'please try your call again later'

Viewing 500 Errors in the Browser

Since the base HTML for your site is not cached on the CDN by default, receiving a 502 or a 504 error in the browser is an indication that the web server is unable to respond to the CDN's initial request to your server for that HTML and then returns a 5xx error.

Let's take a look at a few examples of the different types of messages you might see in a browser when getting a 502 or 504 error.

502 Error:

502 Bad Gateway

HTTP Error 502 Bad Gateway

502 Service Temporarily Overloaded

Error 502

502 Proxy Error

HTTP 502

502 Bad Gateway NGINX

504 Error:

504 Gateway Timeout

HTTP 504 Gateway Timeout

HTTP 504 Error

HTTP 504

504 Gateway Time-Out

Nginx 504 Gateway Timeout

Gateway Timeout (504)

504 Gateway Timeout NGINX

Note each error has multiple examples with different wording, but they all mean the same thing. The wording can vary from site to site.

Viewing 500 Errors in the terminal

To confirm these errors via terminal, you can use the cURL command to send an HTTP request to your site via your Edge Address:

curl -I myEDGEADDRESS.stackpathcdn.comHTTP/1.1 504 Gateway Timeoutdate: Thu, 13 Dec 2018 14:53:45 GMTaccept-ranges: bytescache-control: max-age=10X-HW: 1544712810.cds078.da2.h2,1544712810.cds117.da2.sc,1544712825.cds117.da2.paccess-control-allow-origin: *Connection: keep-aliveContent-Length: 0

Fig A - an example of a 504 response while running 'curl -I' against a StackPath customer's Edge Address.

First, cURL against the Edge Address to make sure that the CDN is proxying the connection to the origin. In the example above we can see a couple of key bits of information to take note of:

A response of 504 Gateway Timeout is present

The X-HW header ends in ' .p ', indicating that this request was proxied to the origin, not served from cache.

The X-HW is inserted by the CDN and can tell us where an asset is served from, what PoP the request is going to, and whether or not the response came from cache or was from a proxied connection to the origin.

When the CDN is proxying a request, it is simply passing the request to the origin server and then reporting back to the browser what it receives. In this case, the server gave a 504.

To find a root cause there are a number of troubleshooting steps StackPath recommends. The rest of this article will walk through the most common ones.

Troubleshooting the '502 Bad Gateway' error

Common causes for this particular error are:

The CDN is not connecting to the correct server

Ensure that the IP address set in your Origin Information is correct.

If using a domain in your Origin Information, ensure it resolves back to the correct IP address

A firewall or other security device is blocking the request:Something that is not your origin is blocking the request from the CDN.

Check that your firewall is not dropping requests from our CDN

Make sure that any DDoS protection you might have has not been triggered by origin pull requests from the CDN.

Some CMS security plug-ins may also be the culprit - try disabling them and refreshing your site to rule this out.

Make sure you have Whitelisted all the Stackpath IP Blocks on your server's firewall (link will open a new window)

The domain is not resolving properly

Double check your DNS records are properly configured and properly propagated.

Use a tool like What's My DNS to check on how your records are configured.

Origin pull is encountering a redirect loop

Curl the origin URL and see where it is redirecting. Oftentimes a redirect loop is due to the origin trying to redirect to itself or the CDN, and we attempt to follow that redirect as the default behavior.

The most common fix is to set the "Origin Pull Policy" in StrikeTracker to "HTTP or HTTPS". This will allow the CDN to obey any redirect protocol changes from your origin.

For more information on troubleshooting 502 errors, and what is going on during a request that returns a 502, feel free to take a moment to read over this article.

Troubleshooting '504 Gateway Timeout', and other common 5xx Errors

There are a variety of root causes for 504 Gateway Timeout errors. Below is a checklist to follow to diagnose them.

Check that the host header is set correctly in the StackPath Control portal.

Make sure the HTACCESS file is correct on the server.

especially if WordPress has been recently re-installed or restored.

Make sure you have Whitelisted all the Stackpath IP Blocks on your server's firewall (link will open a new window)

Ensure that the server is not having problems at the WordPress level, the Apache/NGINX/WebServer level orat the Operating System level.

Permissions issues in the operating system

Database corruption

Server hardware/infrastructure issues

Issues with server's resources (RAM, Disk i/o, CPU)

Server issues that prevent WordPress from properly accessing its database or other resources can result in the server returning a 504, or at times a 503 error.

If you don't know how or what to check, or don't have access to your server's operating system, you will want to contact your hosting provider to help check on this with you.

If you are still having problems or have any questions regarding 500 errors when visiting your site, please contact our 24x7 support team via chat or [email protected].

The StackPath Web Application Firewall (WAF) supports three modes of operation, Active, Monitor, and Off. Each will allow the WAF to perform different functions.

This article will explain the usage of the Monitor mode and show how to enable it.

Please make sure you have already created and properly integrated a website with the WAF, or with the CDN and WAF together.

What is Monitor Mode for?

Monitor mode is not intended to be turned on permanently. It should be used as a temporary testing method to determine and adjust the WAF's behavior before turning on the WAF.

When the StackPath WAF is in Monitor mode, the WAF logs any incoming requests might be blocked, but it does not issue any actions on them. This allows for testing for potential blocking behavior without impacting (also known as sanctioning ) any users.

What Happens in Monitor Mode?

This process allows requests through but creates a Security Event if the request would otherwise receive a sanction. This allows you to see what would have happened and investigate why it would have happened if the WAF were active.

For example, a basic cURL request without any header modification flags triggers the "Invalid User Agent Prevention" Policy, if enabled, and receives a 403 status code:

curl -I https://c8k3p3x4.stackpathcdn.com

HTTP/2 403

date: Mon, 25 Mar 2019 20:38:48 GMT

When the WAF is in Monitor mode, the WAF responds with a 200 status code, but still generates the Security Event:

curl -I https://c8k3p3x4.stackpathcdn.com

HTTP/2 200

date: Mon, 25 Mar 2019 20:40:37 GMT

StackPath Control Portal

Please Note: The WAF does not actually initiate any events to end users, so certain Policy triggers that rely on human input (JS Validation or Captcha) will display significantly more blocked request in Monitor mode than when the WAF is active.

Implementing WAF Monitor Mode

To enable monitor mode for a WAF site, please follow these steps.

Log in to the

Select the Sites menu on the left menu bar, and click the domain for the intended WAF site to manage

Select WAF on the side bar. Under WAF Mode, the options provided are Protect and Monitor. When Monitor is selected, it is indicated by an orange magnifying glass on the top menu bar next to the WAF option.

You may also confirm "Monitor Mode" is shown on the upper right corner of the WAF Usage Chart by navigating to Analytics > WAF

This guide assumes you are using StackPath's WAF without CDN. If you have a packaged plan, both can be used together, this guide explains the setup process for using both the CDN and WAF.

To add a Site, select the Create Site button present on the Sites page.

custom rules

Enter your domain name and click continue, the automated process will guide you through the next steps.

Once completed, a new Site will be added to the dashboard, and show WAF as an enabled service.

Configure Site Origin Settings

Before any DNS records are adjusted, it is best practice to confirm the proper configuration,to avoid any network errors while trying to pull content through StackPath's systems, please confirm the following information within the Site's Settings tab for this domain before proceeding with the integration:

A more detailed explanation for each of these settings can be found here.

Origin Address: This should contain the IP address of the origin server.

Host Header: This field contains the value for the host request header StackPath will send to the origin server, this should be the primary version of the domain to be used. If the website has a redirect in place to force WWW connections, the WWW subdomain should be used in this field.

Origin Pull Protocol:This should match the HTTP version used by the website. If a redirection is enabled for HTTPS enabled on the origin, please set this option to HTTPS Only.

Delivery Domains: TheApex domain and WWW subdomain should be added by default, but please add both if they are not present, along with any other subdomains intend to use with StackPath.

EdgeSSL Settings

If the website uses HTTPS, please ensure an SSL certificate is uploaded or complete the validation process for the free EdgeSSL certificate, provided by StackPath. Free EdgeSSL validation will be completed automatically if your DNS is already migrated to StackPath.

EdgeRules

If HTTPS or WWW redirects are being utilized on the origin server these can be enabled within the EdgeRules tab under Sites > Website Domain > EdgeRules

Configure WAF Settings

The WAF settings will be configured next. We will start with whitelisting IP addresses in the Allowed IPs section. Adding these will prevent false positives from occurring when administrators are working on the site.

Add any administrative users' public IP addresses to the WAF Whitelist in theFirewalltab.

If a CMS is being used, enable the Protection policy for the applicable CMS and whitelist the Origin IP.

Allow Known Bots as applicable.

Origin Security

The final step before integration will be to check any security plugins or firewalls enabled at the origin level to ensure the StackPath IP blocks are whitelisted to prevent any issues with StackPath systems connecting to the origin.

DNS Configuration

Before the StackPath WAF will start protecting your service, DNS must be updated to pass traffic through the WAF. After this step is completed, the StackPath WAF servers will regulate access to your origin and protect your website. To achieve this, point both your apex and relevant non-apex domain at the Edge Address we have provided. Usually, this is the "www" subdomain.

Adjust the record for the WWW subdomain to be a CNAME Record that resolves to the Edge Address provided. The WWW subdomain would look similar to this when using the StackPath DNS.

It is also recommended to point the apex domain to the anycast IP of the Edge Address in order to protect the real server IP from being discovered.

This step should be completed with an ANAME record or through Domain Shortening if offered by your DNS provider, as StackPath's anycast IP is subject to change at any time.

If you encounter any issues or need assistance, please contact our 24/7 support through chat or email at [email protected].

Important Next Steps

Step 1

Add any API URLs into the WAF interface to ensure we protect them properly.

Step 2

Createto enable powerful, customizable traffic monitors.

Monitoring can be used to watch your site's uptime and status. To get things going, you'll need to add a Monitor.

Adding a Monitor

Navigate to the Monitor overview page by clicking Monitoring in the left navigation bar.

Click Create Monitor. Service Check Alerts

Now, enter a name for your Monitor.

Next, select the Source and Enter the URL you wish to monitor then select the request method you want to use. If you're unsure of what to select here, it's most likely that you'll useGET.

Now, select the IP version you want to use for testing. Checks will only be completed with this IP version. If you need to test both IPv4 and IPv6, you'll need to create two monitors. If you're unsure, you should select IPv4.

Select the locations you wish to monitor from. We typically recommend that you select at least 3. However, if your users are concentrated around a specific geographic area, you may want only to pick locations in that area to ensure your tests are relevant. Too many monitors and your server may not be able to handle all the requests at once - requests are issued simultaneously from every location every 5 minutes. While the China location is available, you may see errors from this location due to restrictions on the internet by the Chinese government. If you consistently see errors with the China location, you may want to disable this from the monitor.

Then, adjust the timeout if required. We typically recommend leaving this at 10s. Checks that reach the timeout value will be considered failures. If the check fails, it will be completed again before a failure status is set. There is a hard limit of 20sbefore timeout, even if a higher value is entered in this input box.

Finally, there are options available for basic authentication, digest authentication, and request body content. If your monitor destination requires basic authentication, go ahead and enter your username and password here. If you're testing with a POST request, you can add a request body here too.

Once the monitor isadded to your account, the checks will be queued on the backend. Checks currently run every 5 minutes and are executed at the same time from all locations. Once a check has run, you'll begin to see data in your account for each monitoring location.

Viewing Properties of a Selected Monitor

After creating a monitor, the Monitoring tab will show you that monitor, and the current status.Please note, it may take several minutes before the monitor displays information, as we have to send the request, and receive a response. You can select the Monitor to view more details about its working properties.

Overview will contain all of the information about response time for the source you are monitoring. This tab displays a graph for the average response time across all of the selected Monitor locations and the Response by location below that.

Locationswill contain information about all the locations from which you are polling your website. This will contain the physical location we are polling form, the provider of the polling service, the Average Response Time over the past hour, and the last Status Code that was received from your website.

Alertingwill contain any alerts you have set up for this monitor and the trigger rules for the alert, how many locations at one time will trigger this alert, and how you will be alerted. You also have the option to turn on or off this alert.

Errors will show any errors reported by StackPath's Monitoring locations, what kind of error was received, and the number of locations that are reporting the error.

Your monitor is now up and running; you will be able to log in and view the Status of your Server. To fully take advantageof Monitoring you should set up, so you can be notified of issues when away from the control panel.

A Web Application Firewall (WAF) is an application firewall for HTTP applications. It applies sets of rules and performs behavioral analysis to block malicious traffic from reaching your origin server.

WAF covers known vulnerabilities like OWASP Top 10 and other common CMS specific vulnerabilities. Depending on the threat type, different rules will apply and different actions such as block, captcha, and a JavaScript challenge.

StackPath Web Application Firewall

StackPath's WAF is comprised of a unique 2-tier SaaS. The first tier is a cloud-based Central Security Cloud that analyzes traffic for behavioral profiling, inconsistency detection, and reputation recognition The second tier are edge nodes that enforce security policies and deliver services distributed by the cloud.

When a request matches one of our rules, a challenge (e.g. captcha, JavaScript challenge)will be delivered to the user. For example, if the request contains a string that includes "Select * from db," that SQLi rule will be triggered and the user will be blocked.

Anti Automation protection

Cyber-criminals are increasingly using automation to carry out attacks on web-applications for several reasons, including:

Automation tools enable the attacker to hit more applications and exploit more vulnerabilities than any other manual method.

The automatic tools that are available online and save the attacker the trouble of studying attack methods and coming up with exploits applications are vulnerable to.

These tools are optimizedto use resources more efficiently.

The StackPath WAF behavioralanalysis blocks any non-human traffic from reaching your site. Advanced user behavioral analysis blocks automated scanners, bots and, other automated tools from accessing your application, while known bots will be allowed (e.g. known search engines).

IP Reputation

Some areas of the internet are notorious for the generation and distribution of abusive traffic. These areas might be hacker-operated botnets, zombie servers in hosting facilities that have been infected with malware, and anonymous proxies used by hackers, spammers, and scrapers.

StackPath allows you to blacklist traffic originating from well-known IP addresses, allowing you to block malicious traffic without having to inspect it first. StackPath's Central Security Cloud constantly collects, updates, and validates these IPs using multiple sources and publishes blacklisted IP addresses to all StackPath Service Nodes. Using this intelligence, you can decide whether to block, challenge, or allow traffic from highly suspect entities.

DDoS L7 Protection

StackPath's bot-detection technology blocks bots with an extremely high degree of accurately:

Bots that share IP addresses with human users are blocked while allowing unrestricted access to legitimate users.

Bots that frequently change their IP addresses also fail to evade StackPath's bot detection engine. They are tracked down and blocked again and again.

Conditional origin request routing allows a single StackPath Site to serve content from multiple origins. Through Serverless Scripting, a Site can route requests to a specific origin based on numerous request or response conditions. This article will show you one example of conditional routing, how to route requests to different origins based on the request URL path.

Two examples are provided, the first re-routing a single URL path to an alternate origin, the second re-routing multiple paths to multiple origins.

Single Path

Create Script

Route: /de

Note: this will apply to all requests that have /de in the path. You will need to ensure that all URLs are accessible once making this change, or adjust the route and the script accordingly.

Script:

addEventListener("fetch", event => {

event.respondWith(handleRequest(event.request));

});

function checkSite(url) {

return new URL(url).pathname.split('/')[1]; // we're checking the URL path, e.g. domain.com/something/else would yield something

}

async function handleRequest(request) {

try {

const path = new URL(request.url).pathname; // we need get the url in order to figure out where to route them

request.url = 'https://sitehash0.stackpathcdn.com' + path;

return fetch(request);

} catch (e) {

return new Response(e.stack || e, { status: 500 }); // error handling

}

}

Accessing Your Script

Once the above has been created, you can access your script using any of the delivery domains on your account. In my example, I can access this script with https://sitehash.stackpathcdn.com/de/index and my request will be sent to https://sitehash0.stackpathcdn.com/de/index

Multiple Paths

Create Script

Route: *

Note: this will apply to all requests to your entire site. You will need to ensure that all URLs are accessible once making this change, or adjust the route and the script accordingly.

Script:

addEventListener("fetch", event => {

event.respondWith(handleRequest(event.request));

});

function checkSite(url) {

return new URL(url).pathname.split('/')[1]; // we're checking the URL path, e.g. domain.com/something/else would yield something

}

async function handleRequest(request) {

try {

const path = new URL(request.url).pathname; // we need get the url in order to figure out where to route them

switch (checkSite(request.url)) {

case 'de': // if the request is towards the de, e.g. domain.com/de/something

request.url = 'https://sitehash0.stackpathcdn.com' + path;

case 'fr': // if the request is towards the fr, e.g. domain.com/fr/something

request.url = 'https://sitehash1.stackpathcdn.com' + path;

case 'us': // if the request is towards the us, e.g. domain.com/us/something

request.url = 'https://sitehash2.stackpathcdn.com' + path;

}

return fetch(request);

} catch (e) {

return new Response(e.stack || e, { status: 500 }); // error handling

}

}

Accessing Your Script

Once the above has been created, you can access your script using any of the delivery domains on your account. In my example, I can access this script with https://sitehash.stackpathcdn.com/de/index and my request will be sent to https://sitehash0.stackpathcdn.com/de/index

What is theServerless Scripting Sandbox?

TheServerless Scripting Sandbox ( sandbox.edgeengine.io ) is a great tool for testing your serverless scripts before deploying them to our edge. Before diving deeper into the sandbox, it's worth briefly running through what Serverless Scripting is.

Serverless Scripting is a platform that enables you to upload JavaScript scripts on a per-site basis that can interact with any and all requests coming through your StackPath site, allowing you to manipulate requests before reaching the edge or your origin. This also allows manipulation of response data before reaching the client (among other use cases). To learn more about the basics of Serverless Scripting with examples, you can view our online documentation here.

What can I do with Serverless Scripting Sandbox?

You can freely test your scripts before deployment to ensure they work as expected. The first major element of the sandbox is the simple to use code editor, which you should be familiar with if you've used Serverless Scripting before.

The editor includes code complete and contextual information on hover (including errors), as seen in the screenshot: https://www.google.com

Next, we can look at the request window. Here, you can choose between an Iframe, which will give you a browser-like visual experience, or Raw, which will issue requests and return the resource as text:

The final element of the sandbox is the console, which is great for debugging your scripts on the fly, and also for confirming your script is working as intended:

Using Sandbox with an example

Here's an example script for our Sandbox. It will take an array of paths that will be redirected back to the apex domain if the path is found in the user's request:

// Redirect users based on pathaddEventListener("fetch", event => { event.respondWith(handleRequest(event.request));});/** * Fetch and return the request body * @param {Request} request */async function handleRequest(request) { try { /* Fetch the response */ console.log(request.url); let response = await fetch(request); /* Set our paths that will be redirected, and the Location header which is the URL we will redirect to */ var paths = ["/path1", "/path2"]; const modifiedHeaders = new Headers(response.headers); modifiedHeaders.append("Location", ""); /* Here, we chech each path in the paths against the request URL */ paths.forEach(item => {if (request.url.search(item) != -1) { /* If we match, we edit status code, text, and headers to redirect back to apex URL */ response.status = 301; response.statusText = "Moved Permanently" response.headers = modifiedHeaders return response; }}); /* If we don't find a desired path in the request URL, we don't edit the response */ return response; } catch (e) { return new Response(e.stack || e, { status: 500 }); }}

We're going to use this script as an example, so feel free to read through the comments. With the script in place in Sandbox, let's observe the results.

Request #1

https://google.com/path1

Note that "/path1" is in our paths variable, so we want users to be redirected. Let's take a look at the response:

The default response for that path is a 404 page since it doesn't actually exist, however, the request works for our purposes. You can see we hit Google's homepage, which suggests we got redirected successfully. You can confirm this by looking at the console, where we're logging request URLs. Note that the last URL is the pathless URL, which is what we want.

Request #2

https://www.google.com/path3

This path isn't in our paths variable, so we don't want to redirect. We expect a 404 page:

As expected, the response wasn't edited and we didn't get redirected. This is a simple example that we hope will display what Serverless Scripting can do, and how you can test your scripts quickly and easily before deployment.

WP Rocket is a caching and performance optimization plugin for WordPress that improves page load time. Installation and configuration can be completed in less than 3 minutes.

This article will walk you through how to perform a static assets integration, which does not support the use of the StackPath Web Application Firewall (WAF). If youre looking to maximize security by using our CDN with the WAF, please refer to the CDN & WAF integration guide.

Before you begin, we highly recommend you test the performance of your site using Google Page Speed or Pingdom Tools. You can test your site now and after setting up the plugin for a before and after performance comparison. This tutorial assumes you've already gone through the steps to create a StackPath Site and the WP Rocket plugin is purchased.

Installation

Log in to the WordPress admin panel:

StackPath SSL Options

On the left-hand menu, hover over Plugins and select Add New:

At the top of the page, click Upload Plugin.

Click Choose File. Then grabthe WP Rocket plugin file from the folder you saved it to. After selecting it click Install Now.

Click Activate Plugin.

Configuration

In the top menu click the WP Rocket link.

Click the CDNtab.

Enter your Edge Address in the text field called CDN CNAME(s).

Save the changes.

Verify the source code of any page to confirm that the CDN domain is being used for static assets instead of your origin domain. Your Edge Address should precede directories designated for static content is located.

Test Speed and SEO after Stackpath CDN is enabled

At this time, you should perform another speed test by using Google Page Speed and Pingdom Tools.

Compare the before and after tests and note that it can take one to seven days for your site to reflect the performance improvements of a CDN. Both of these test sites also will give you SEO recommendations that you can follow.

What's Next?

Feel free to take a look at these articles for some possible next steps with your CDN Integration:

CDN Configuration Settings Explained

CORS Header Configuration

In the event you have problems with the integration, we have 24/7 integration assistance via live chat by clicking our chat bubble at the bottom of this page! We are always happy to help answer questions and to help make sure you experience the fastest and most secure experience with Stackpath CDN.

Edge Computing VM's are provisioned from images which are configured with a default user. No passwords are set on creation, so you will need to ensure you Generate SSH Keys and have added them to your workload during workload creation before attempting to connect to your instance.

Default Users

The default user is based on the Operating System image you have used. You can find the default user in the table below:

Operating System

Username

CentOS 7

centos

CentOS 7 - cPanel/WHM

centos

CentOS 8

centos

Debian 10 Buster

debian

Ubuntu 18.04 LTS

ubuntu

Ubuntu 19.04

ubuntu

The default users have sudo permissions enabled.

When connecting via SSH, you will need to use the username listed in the table above. For example:

ssh centos@[instance.ip]

ssh debian@[instance.ip]

ssh ubuntu@[instance.ip]

Adding Users

Once your instance has deployed, you can add users to your instance using the adduser command as you would on any standard Linux distribution.

For example, to add the user john:

sudo adduser john

You can then set a password for the user:

sudo passwd john

If desired, add the user to the sudo group: Debian:

sudo usermod -a -G sudo john

Redhat:

sudo usermod -a -G wheel john

Since password logins are disabled, you will have to add a public SSH key for this new user. To enforce user permissions we will add the key to the new user's profile, and not the root user.

On the virtual machine:

sudo su - john

And edit the authorized keys file for the new user and append a public rsa key.

~/.ssh/authorized_keys

Or on a remote machine with root VM access:

ssh-copy-id john@vm_ip_address

Congratulations, you have now added an additional user to your VM and have the ability to modify permissions and access.

If you have any additional questions or concerns, feel free to reach out to StackPath Support via [email protected] or over our 24/7 live chat.

There are two options for integrating StackPath's CDN. This article utilizes the recommended Full Site CDN delivery method, which is achieved through modifying DNS records. This method of integration will allow the StackPath CDN to cache all of the content on an origin, and accelerate the entire website.

This guide primarily focuses on the CDN Configuration, if you would like to configure a Site to use both CDN and WAF, please use the guide for CDN with WAF Integration.

About this Integration

The integration process will work with any subdomains for the primary domain but has been written with the common WWW subdomain in mind primarily. If a separate custom subdomain (blog orinfo) is desired, simply replace any instance of WWW with the custom subdomain.

This integration will involve adjusting DNS records for full site acceleration and protection, the StackPath DNS is recommended, but this is not a required service for this integration.

Add the Domain

Sites can be created with CDN enabled, as long as the Stack in question includes the StackPath CDN Service.

Log into the StackPath Control Portal

Navigate to theSitespage, and select Create Site Pingdom Tools

Enter the domain name for the integration

Select theCDN checkbox(along with any other services desired)

SelectContinue

Confirm the Origin server data is correct and selectContinue again

This will generate the Site for the domain entered in Step 2 along with an Edge Address for the Site.

Configure Site Origin Settings

Before any DNS records are adjusted, it is best practice to confirm the proper configuration, to avoid any website downtime after the DNS records are adjusted.

Origin Configuration

To avoid any network errors while trying to reach the website through StackPath's systems, please confirm the following information within the Site settings for this domain before proceeding with the integration:

Origin Address: This should contain the IP address of the origin server.

Host Header: This field contains the value for the host request header StackPath will send to the origin server, this should be the primary version of the domain to be used. If the website has a redirect in place to force WWW connections, the WWW subdomain should be used in this field.

Origin Pull Protocol:This should match the HTTP version used by the website. If redirection is enabled for HTTPS enabled on the origin, please set this option to HTTPS Only.

Delivery Domains: TheApex domain and WWW subdomain should be added by default, but please add both if they are not present, along with any other subdomains intend to use with StackPath.

EdgeSSL Settings

If the website uses HTTPS, please ensure an SSL certificate is uploaded or complete the validation process for the free EdgeSSL certificate, provided by StackPath. Free EdgeSSL validation will be completed automatically if DNS is already migrated to StackPath.

EdgeRules

If HTTPS or WWW redirects are being utilized on the origin server these can be enabled within the EdgeRules tab under Sites > Website Domain > EdgeRules

Testing the Integration

Before completing the DNS Record Adjustment,please adjust your local Hosts file to force your domains to resolve to StackPath's services. This article provides instructions for integration verification.

Adjusting DNS Records - Go Live

With all of the preparation complete, the final step is to adjust DNS records to resolve the domain(s) to StackPath. This can be done via StackPath DNS (if the nameservers were already migrated); or via the current DNS provider, if not using StackPath DNS. This process will vary based on the DNS provider.

Adjust the record for the WWW subdomain to be a CNAME Record that resolves to the Edge Address provided. The WWW subdomain would look similar to this when using the StackPath DNS.

It is also recommended to point the apex domain to the anycast IP of the Edge Address in order to protect the real server IP from being discovered.

This step should be completed with an ANAME record or through Domain Shortening if offered by your DNS provider, as StackPath's anycast IP is subject to change at any time.

Test Speed and SEO Post Integration

At this time, please perform another speed test by using Google Page Speed and.

Compare the before and after tests and note that it can take one to seven days for a website to reflect the performance improvements of a CDN. Both of these test sites also will give SEO recommendations.

If you decide to use a different provider for DNS hosting and you want to use StackPath as your CDN/WAF provider, you must update DNS with your DNS provider to complete the integration.

The methods below apply to either static content or full-site content delivery, using a CNAME record in your DNS manager.

If you would like to utilize the StackPath CDN with using an apex (or root domain) you will need to use StackPath for your primary DNS provider. This method requires a CNAME, like "www.example.com" be used for content delivery.

This tutorial will walk you through the basics of connecting your domain to the StackPath CDN with whichever particular DNS provider you use to manage your DNS records.

If you see a DNS provider with incorrect instructions, please use live chat on this page to report it to our Support team.

Select Your DNS Provider

Cloudflare DNS

123reg DNS

GoDaddy DNS

Bluehost DNS

DYN DNS

DNS Made Easy

Clou DNS

Easy DNS

1&1 DNS

Blacknight DNS

DNS Park

Network Solutions DNS

EveryDNS

eNom DNS

EuroDNS

Gandi.net DNS

Hover DNS

IX Web Hosting DNS

MyDomain.com DNS

myhosting.com DNS

Namecheap DNS

No-IP DNS

Register.com DNS

Registo.br DNS

Terra Domnio DNS

Upperlink DNS

Yahoo!SmallBusiness DNS

ZoneEdit DNS

Cloudflare DNS

Login to your Cloudflare account.

From the dropdown menu on the top left, select your domain.

Select the DNS settings tab.

Add the CNAME records. In the first field enter the subdomain you would like to use ( example: CDN) and in the second field enter your Edge Address (foo-bar.stackpathdns.com).

123reg DNS

Log in to your 123-reg control panel

Have a look in the Domains section.

Select your domain name using the drop-down menu and then click on the Manage button.

In the advanced domain settings menu, click Manage DNS.

Now click on the Advanced DNS tab.

Using the drop-down menu, select CNAME.

In the hostname field enter CDN ( or WWW for full site cache). In the Destination CNAME field enter your Edge Address ( foo-bar.stackapthdns.com). Onceyou'veentered the details click Add.

GoDaddy DNS

Log in to your GoDaddy account.

On your product list next to Domains, click the plus sign button to expand the list.

Next to the domain you want to manage, under the Action section, click on the Manage DNS button.

At the bottom of the Records section, click Add and select CNAME from the drop-down list.

Complete the other fields:Host - Enter the subdomain name for the alias assignment. For example, type www. The subdomain can include a period (.) but not as the first or last character. Consecutive periods (...) are not allowed. A subdomain cannot exceed 25 characters.Points to - Enter the host name you want the alias to point to. For example, type @ to map the alias directly to your root domain name.TTL - Select how long the server should cache this information.

Click Save.

BluehostDNS

Log into your Bluehost Hosting Account.

Select the DNS Zone Editor icon in the Domains section.

Select the domain you're modifying from the drop-down box.

Scroll down to the heading named Add DNS Record.

In the Host Record field, enter the desired record name.

Leave the TTL field at it's default setting.

Select CNAME, from the drop-down labeled Type.

In the Points To field, enter the address that the record should resolve to.

Other fields may appear depending on the type of record you are creating.

Click on the Add Record button to create the record.

DYN DNS

Log in to your Dyn account, locate the My Services option.

Locate the Zone you wish to add a record to, and click on Dyn Standard DNS Service to the right of the zones name.

When you click the Add Alias (CNAME)button, a new box will come up prompting for Hostname, and Alias To. Hostname must be populated in order for a CNAME to be created. Populate these fields with the appropriate information, then press Create Record. If you are unsure of what goes in these fields, contact our support staff through live chat or email.

DNS Made Easy

Select the DNS Menu.

Select Managed DNS.

Select a domain from the either the Recently Updated Domains box, or start typing the domain name in the textbox on the Select Domaintab.

Under CNAME Recordsclick the plus sign to add a new record.

in theNamefield, type the subdomain you would like to use. In theAlias To field, type the URL you would like to link the subdomain to (to alias to the root record of the domain name, you leave thisvalue blank).

Click Submit.

Clou DNS

Go to your Control Panel and click on Add new record.

Type the following:Type: CNAMETTL: 1 Hour Host: example (www.hostname.com)Points to: Edge Address (ex. foo-bar.stackpathdns.com)

Easy DNS

Log into your easyDNS account.

Click on the DNS link for the desired domain (this will bring you to the DNS SETTINGS page).

Click on either STREAMLINED EDITOR or MODULAR EDITOR (recommended).

Click on the green wrench tool for theDNS recordtype you are trying to create.

1&1 DNS

Log in to your account at https://admin.1and1.com

If you have only one package, you will land on the Administration page. Proceed to step 4.

If you have more than one package, select the package with the domain you're trying to verify. The Administration page for the specified domain appears.

Under Domains & Web Space, click Domain Center. The Domain Overview page appears.

Select the box to the left of the domain you would like to verify. A blue check will appear.

From the New drop-down menu, select Create Subdomain.

Enter the following code [TOKEN] in lowercase letters, and click OK.

Press the yellow + symbol next to Subdomain Overview.

Check the box next to the subdomain. The subdomain should now read: token_code.yourdomain.com.

Click the Subdomain Settings button, and select Edit DNS settings in the drop-down menu.

Click the radio button next to CNAME.

Next to Alias, enter [TOKEN] in lowercase letters.

Click OK.

Blacknight DNS

Sign in to your account at: cp.blacknight.com

Click Registered Domains.

Select Manage DNS for the domain you are trying to verify.

Click the DNS tab.

Click the DNS Records tab.

Select Add New DNS Record.

In the pulldown menu for DNS Record Type, select CNAME.

Enter your CNAME in the field marked Domain.

Enter the address you wish the CNAME to point to in the field marked Canonical Name.

Click Finish.

DNS Park

Log in to your account at DNS Park.

On the left side, click DNS Hosting.

Click the domain you'd like to use with GSuite.

Since DNS Park is your hosting service, and not your domain registrar, be sure that your domain points to DNS Park's nameservers. This will allow your CNAME record configuration to take effect.

Click Alias Records.

Include the CNAME record value associated with your use with the name in the Host Name field and the value in the Destination Name field.

Click Add Alias.

Network Solutions DNS

Go to www.networksolutions.com and click Manage Account.

Enter your user ID and password, select Manage All Services from the pulldown menu, and click Login.

Click Manage Domain Names.

Select the domain name to receive new DNS records and click Manage.

Click Change Where Domain Points.

Click Advanced DNS.

Under the Host Aliases (CNAME Records) heading, click Add/Edit.

Enter your CNAME records, depending on the type of CNAME records you are creating.

Select the radio button to the left of the Other Host box.

In the Other Host field, enter the corresponding Value/Answer/Destination from the same CNAME record values table.

Click Continue.

Review your changes and click Save Changes to create the CNAME record.

EveryDNS

Log in to your account at EveryDNS.net.

On the left side, click the domain you'd like to use with GSuite for Your Domain.

Since EveryDNS.net is your hosting service, and not your domain registrar, be sure that your domain points to EveryDNS.net's nameservers. This will allow your CNAME record configuration to take effect.

Below Add a Record:, you can create your CNAME record.

Include the CNAME record value associated with your use with the name in the Fully Qualified Domain Name field and the value in the Record Value field.

Select CNAME as the Record Type.

Click Add Record.

eNom DNS

Log in to your account at www.enom.com.

From the drop-down menu at the Domains tab, select My Domain. You'll be directed to the Manage Domains page.

Click the domain that you'd like to use with GSuite.

Click Host Settings.

To add a CNAME record, click NEW ROW. If you've already created a CNAME record for the address, simply edit the existing CNAME record.

Enter your CNAME record.

As the host name, enter your Edge Address(ex. foo-bar.stackpathdns.com).

Click Save.

EuroDNS

Log in to your account at eurodns.com.

Click My Domains in the My Domains menu on the left side of the page. A table listing your domains should appear.

Click the DNS column on the row of the domain you wish to change. The DNS records for your domain should now be displayed. Enter your CNAME record using the examples listed in the CNAME record values table.

From the Add... drop-down menu of the HOST NAME table, choose Host Alias, and click the Add button next to it.

In the Alias: field, add your custom domain. For example, if you chose cdn.mydomain.comas your address, enter cdn.

In the Host Name: field, add Edge Address(ex. foo-bar.stackpathdns.com).

Click the Save Settings button.

Gandi.net DNS

Log in to your account at gandi.net.

Click the Administration tab, and then click the control panel link.

Click the domain you want to manage, and go to Technical Settings.

Click Manage DNS zone file.

Enter your CNAME record using the guidelineslistedbelowName: Enter your custom URL prefix (such as cdnor www).Type: Select CNAME.Value: Enter Edge Address(ex. foo-bar.stackpathdns.com.), making sure to include a trailing dot (.) at the end of the value.

Click Submit.

You should be back to the list of entries. Click Submit Changes.

Hover DNS

Sign into your account at: https://www.hover.com/login

Select the domain.

Go to the DNS tab.

Click Add Record.

Select CNAME from the pulldown menu.

Enter your CNAME recordFor example, to direct www.mydomain.com to your CDN, enter wwwin the Hostname field and Edge Address in the Target Host field.

Click Save.

IX Web Hosting DNS

Log in to your account at ix web hosting.

Click Manage below the Hosting Account section.

On the left side, click the domain you'd like to use with GSuite.

Next to DNS Configuration, click EDIT.

Click Add DNS CNAME Record.

Include the CNAME record value associated with your use with the name in the Name field and the value in the Data field.

Click Submit.

MyDomain.comDNS

Log in to your account for your domain at www.mydomain.com/

Click on the My Services tab.

Under Manage My Services, click on Manage Services.

Go to Domain Overview.

Click on Domain Administration.

Select the domain you're using with GSuite.

Click the DNS tab, and select DNS Records.

Click Add New DNS record.

From the drop-down menu, select CNAME, and click Next.

Include the CNAME record pointed towards the Edge Address.

Click Finish.

myhosting.com DNS

Log in to your account for your domain at http://myhosting.com.

Go to http://myhosting.com.

Click on the Account link at the top of the page.

Log in with your Domain Name and Password.

Click on the Domain Name tab.

Click DNS Management in the left-hand pane.

Click the Manage DNS button.

Add an Alias (CNAME) record pointed towards the Edge Address.

Click Save.

Namecheap DNS

Log in to your account at www.namecheap.com.

Go to My Account > Manage Domains and choose the needed domain name from the domain list.

Select All host records.

Include the CNAME record value that will point to your Edge Address.

Click Save and you are done.

No-IP DNS

Log in to your account at No-IP.

On the left side, click Host/Redirects.

Click Manage underneath Host/Redirects.

Click Add for a new entry, or click Modify and skip to step six for an existing entry.

Include the CNAME record value associated with your use with the name as the host name and the value in the Target Host field.

Select DNS alias CNAME at the host type.

Click Modify.

Register.com DNS

Log in to your account at register.com

Under the My Accounts tab, click the domain that you're using with GSuite

Scroll down to the Advanced Technical Settings heading, and click Edit Domain Aliases Records

In the first field, enter the Name/Host/Alias from the CNAME record values table, depending on the type of CNAME record you are creating.

In the second field, enter the corresponding Value/Answer/Destination from the same CNAME record values table.

Click Continue

Review your changes, and click Continue to create the CNAME record.

Registo.br DNS

Log in to your account for your domain at registro.br.

Select the domain name to receive the new DNS record.

Click Save and Edit DNS.

Click + Record.

From the pulldown menu, select CNAME.

In the first field, enter the Name/Host/Alias, depending on the type of CNAME record you are creating.

In the second field, Dados, enter the Edge Address.

Click Save.

Terra Domnio DNS

Log in to the main email account for the domain.

Write a message to [email protected] requesting creation of a new CNAME record or update to an existing record.

Add to the message the companys C.N.P.J. (Cadastro Nacional da Pessoa Jurdica).

Include the CNAME record pointed towards your Edge Address.

Send the message and await a response.

Upperlink DNS

Log in to your account at dns.upperlink.com.ng.

From the Domain list, click on Manage Domain DNS for the domain name you want to modify or add CNAME records.

If the custom CNAME record that you want to add exists, please remove it first.The CNAME will appear as customcname.yourdomain.com. under the Zone Name field. For example, a custom CNAME like cdnfor a domain name like mydomain.com, it will appear as cdn.mydomain.com. under the Zone Name field.

Enter the following information:Under Zone Name fields change the default value to your custom CNAME (e.g. www, cdn, site etc).Under Zone Type select CNAME from the drop down.Under Zone Value enter your Edge Address.In the content field, Enter your Edge Address.

Click Save.

Yahoo!SmallBusiness DNS

Log in to your account at smallbusiness.yahoo.com.

Click Domain Control Panel below the domain you'd like to use with GSuite.

Click Manage Advanced DNS Settings.

Click Add Record.

Include the CNAME record value associated with your use with the name in the Source field and the value in the Destination field.

Click Submit.

ZoneEdit DNS

Log in in your ZoneEdit account at http://www.zoneedit.com.

Click on the name of the domain name you like to create the CNAME record for.

Click Aliases (CNAME).

Include the CNAME record pointed towards your Edge Address.

Save your changes.

The following records are currently supported by StackPath DNS.

A

Also known as "Record Address Mapping". A records are used to map domain names to IPv4 addresses. The record contains a specified host IP address as it's value and a registered domain as its name.

AAAA (IPv6)

"IPv6 Address Mapping Records" are used to map domain names to IPv6 addresses. The record contains a specified host IP address as it's value and a registered domain as its name.

CNAME

A CNAME (Canonical Name) record is used to point one domain name to another domain. CNAME queries typically require more time to resolve than A records because more queries must be resolved before an IP address is returned. These records are primarily used when routing external domains or mapping multiple domains to one IP address.

MX

An MX (Mail Exchange) record is used to specify a mail exchange server address. SMTP uses DNS information to route requests to IP addresses.

TXT

Text Records are used to store strings of information in DNS. TXT records can be various type of informational text. Often used for SPF, a service used to allow incoming emails to be screened by the mail exchanger.

NS

Name Server records stores information for a host on where to find it's Authoritative Nameservers.

CAA

Certification Authority Authorization (CAA) records are used to determine which Certificate Authorities (CA) can issue certificates for a given domain.

SRV

A Service record (SRV) details information about a services or services. Generally listing, the name, port, and domain that a service operates on.

WP Fastest Cache is a web performance plugin that helps web administrators manage caching inside the WordPress CMS. It comes with a built-in feature for integrating the StackPath CDN, as well as other web performance features.

This article will walk you through how to perform a static assets integration, which does not support the use of the StackPath Web Application Firewall (WAF). If youre looking to maximize security by using our CDN with the WAF, please refer to the CDN & WAF integration guide.

Before you begin, we highly recommend you test the performance of your site using Google Page Speed or Pingdom Tools. You can test your site now and after setting up the plugin for a before and after performance comparison. This tutorial assumes you've already gone through the steps to create a StackPath Site.

To implement StackPath CDN on your website using WP Fastest Cache plugin, follow the steps below.

Log into your WordPress admin panel. StackPath SSL Options

SelectPluginsfrom the left menu and click Add New.

In the Searchbox, type WP Fastest Cache and click Search Plugins.

Click Install Now. A prompt dialog will open and ask if you are sure you want to install the plugin. Click OKand after the plugin is installed, click Activate Plugin.

Configuration

Configure WP Fastest Cache with the following default settings. (please note that the configuration for this part is not tested on all themes and websites so certain websites might need a different configuration)

Go to CDNtab and select CDN byStackPath.(MaxCDN is another platform under StackPath, but both are using MaxCDN option in this setup)

On the following window, click Nextto proceed with the integration.

On this window, you will be entering your Edge Address in the "Enter CDN URL" box. Your Edge Address is provided when you create your site in StackPath. Followed by Origin URL which should match your domain name (Origin URL) that you used to create the site.Note that this plugin requires http/https prefix. Match the one you are using, otherwise, implementationwon'twork.

Now choose which files you want CDN to serve from your website.

Skip specifying of the sources by clicking Next.

Next windows will acknowledge your CDN configuration and confirm that CDN is integrated. Click Finishand then Close.

After these steps are completed, you should purge the cache in order for the settings to be applied. This option can be found on Delete Cachetab.

Test Speed and SEO after StackPath CDN is Enabled

At this time, you should perform another speed test by using Google Page Speed and Pingdom Tools.

Compare the before and after tests and note that it can take one to seven days for your site to reflect the performance improvements of a CDN. Both of these test sites also will give you SEO recommendations that you can follow.

What's Next?

Feel free to take a look at these articles for some possible next steps with your CDN Integration:

CDN Configuration Settings Explained

CORS Header Configuration

In the event you have problems with the integration, we have 24/7 integration assistance via live chat by clicking our chat bubble at the bottom of this page! We are always happy to help answer questions and to help make sure you experience the fastest and most secure experience with Stackpath CDN.

StackPath provides near real-time insights to help you keep a pulse on your site performance.

All analytics are reported in 5-minute intervals and are typically up to date within 10 minutes.

Timeframe selection

Youll find the Timeframe selector in the upper-right corner where you can select the time frame you're interested in analyzing.

Data will be refreshed automatically when selecting a new timeframe.

CDN Graphs and Statistics

The following graphs are available on the CDN overview page.

Bandwidth

The Bandwidth graph will show you information on the amount of bandwidth used from delivering CDN assets(Edge Bandwidth), and the bandwidth from performing origin pulls (Bandwidth to Origin).

Requests

The Requests graph will show you the number of individual HTTP requests handled by the CDN(Edge Requests), and the number of requests that were sent to the origin for assets that were not in cache(Requests to Origin).

Delivery by Data Center

A bubble map of which StackPath data centers delivered your content and how much they respectively delivered.

Cache Hit Ratio

A graph of the proportion of your traffic that required accessing your origin, both transfer and requests. The purpose of these metrics is to give a high-level understanding of how efficiently you are utilizing the CDN's cache from both bytes-transferred- and individual-hit ratios. The higher the ratios are, the more efficiently you are using the CDN

The Transfer Hit Ratio is calculated by taking the amount of data delivered from the CDN Cache, divided by the total amount of data delivered by the CDN (including cache misses) for a given month. Higher hit ratios are preferred, showing a large amount of CDN data delivery with a small number of Origin pulls.

The Request Hit Ratio is calculated by taking the number of requests to the CDN Cache, divided by the total number of requests to the CDN (including ones that result in Origin Pulls) for content delivery in a given month. Higher Hit ratios are desired, indicating a large number of hits from the CDN, with a small number of requests to the origin.

Depending on the kind of content you are hosting, and how often content is updated, the cache hit ratio will vary.

StackPath Edge Computing allows you to deploy containers or virtual machines (VM) on a platform with more diverse PoP locations than centralized cloud providers, getting your workload closer to your end users and clients.

Before walking through the setup process, lets first review a few options that will be available for use in Edge Computing Workloads.

Virtual Machine (VM) or Container?

What's a Container?

Containers allow you to package application code, dependencies, and configurations into a single object that can be deployed in any environment. Containers are created from container images. There is an Open Container Initiative which aims to set industry standards regarding container formats.

What's a Virtual Machine?

A virtual machine is a full software emulation of a physical computer and can perform all tasks a typical operating system normally would. Each virtual machine runs a full operating system and is allocated virtualized system hardware.

VMs versus Containers

That kind of software virtualization is the best fit for your workload? There are a few factors that play into the decision.

Application diversity

Virtual machines are optimal when running many different applications on a single machine - a jack of all trades. Containers are optimal for efficiently and typically run many copies of the same application.

Resource consumption

Unlike virtual machines, containers do not virtualize hardware. Instead, they share the OS kernel with the host. This allows containers to be lightweight in terms of size and CPU and Memory resources used, while a VM requires more resources and startup time.

Deploy directly from testing to production

Maintaining your applications on a container or VM means that you can test, deploy and scale on any machine.

Anycast IP Address

All instances will be assigned internal and external IPs to allow direct access to each instance individually. These IPs are ephemeral and may change if the instance state changes. Ticking this option will allocate an anycast IP for the whole workload which is static for the lifetime of that workload.

Traffic directed to the anycast IP will enter the StackPath Network at the closest Edge Location, and will then be routed to the nearest location where the workload has instances running. Traffic will be balanced across all instances running in that location but there is no guarantee that this will be even across all instances. This means the anycast IP acts as a pseudo-load balancer, considering both the regional latency of the closest edge to the traffic source as well as spreading traffic across all running instances. At present, this routing logic is non-configurable, has no balance guarantee and there is no advanced balancing logic involved. Future plans include more advanced load balancing functionality. Example 1: If a Workload is deployed with instances running in Dallas and London, and a visitor makes a request to the anycast IP from London, their traffic will enter the StackPath network in London and hit the instances running in London. Example 2: If a Workload is deployed with instances running in Dallas only, and a visitor makes a request to the anycast IP from London, their traffic will enter the StackPath Network in London and will then be routed over the StackPath private backbone to hit the instances running in Dallas.

Create a New Workload

StackPath Edge Computing uses the concept of Workloads to organize different applications. A Workload can consist of one container or VM image that is deployed to one or many locations. Traffic is routed to the instances running in the workload either via direct, static IPs assigned to each instance or using an Anycast IP to route traffic to the closest StackPath location.

Select Workloads from the left menu.

Select Create Workload. StackPath website

Specify the configuration for the new Workload (see below).

Select Create Workload.

The Workload will be deployed within a few seconds.

Container Configuration

Name: Each Workload has its own name which allows unique identification when there are many workloads running. Docker Hub. For example, specifying nginx:latest will pull the latest Nginx image.

Image: A URL to a container image hosted somewhere else can also be specified and the workload will pull it down. The URL should be in the same format that would work with docker pull i.e. URL/IMAGE:TAG

Environment Variables: One or many key/value pairs can be supplied as environment variables. These will be available to all instances running in the workload.

Add Anycast IP Address: All instances will be assigned internal and external IPs to allow direct access to each instance individually.

VPC: Currently, workloads are assigned to a default VPC. A future release will open up more functionality for managing networks and multiple VPCs.

Public Ports: By default, all traffic to the workload is denied. Specify which ports to open via TCP or UDP to allow traffic.

Commands: Specify one or many commands that will be executed when each instance starts. Arguments can be passed as if they were additional commands.

Spec: Choose the instance type that will be deployed to the Workload. All instances will be the same type. Every instance has a root SSD sized depending on the instance type selected. These disks are ephemeral and will be deleted when the instance is deleted (including if the instance dies unexpectedly). Available types and pricing are listed on the StackPath website.

VM Configuration

Name: Each Workload has its own name which allows unique identification when there are many workloads running.

Image: The OS image that will be deployed when the workload is created. The image will be pulled from a predefined list of options. For example, specifying CentOS 7 will pull the latest version of CentOS.

VPC: Currently, workloads are assigned to a default VPC. A future release will open up more functionality for managing networks and multiple VPCs.

Add Anycast IP Address: All instances will be assigned internal and external IPs to allow direct access to each instance individually. T

Public Ports: By default, all traffic to the workload is denied. Specify which ports to open via TCP or UDP to allow traffic.

SSH Key: One or more public SSH keys are required when creating a VM. Since password logins are disabled and not assigned, SSH will be your access point. If you don't yet have an SSH key, refer to our Generating an SSH key guide.

Spec: Choose the instance type that will be deployed to the Workload. All instances will be the same type. Every instance has a root SSD sized depending on the instance type selected. Available types and pricing are listed on the .

Deployment Targets

Workloads can be deployed to one or many locations, with specific instance numbers for each set of target locations.

Name: A display name for the location specification.

PoPs: One or many locations where the workload will be deployed.

Enable Auto Scaling: Autoscaling based on deployment targets. Set a minimum and maximum number of instances, based on the percentage set for CPU utilization. Autoscaling is horizontal, not vertical, meaning currently you cannot increase the performance of a system, from 4x8 to a 12x64, for example. One thing to note with VM scaling, it will deploy another VM, within the same PoP, with the OS template chosen for the workload (ie: CentOs, etc). It will not install your apps. You should still use auto-deploy tools such as Puppet, Ansible, etc. to make sure the new VM is setup the same as the existing VM.

Instances Per PoP: The number of instances to be deployed as part of this location specification. The number of instances will be deployed to each location e.g. if the config specifies 2 instances per PoP and selects London and Frankfurt, a total of 4 instances will be deployed. Failed instances will be automatically restarted to ensure this number is always maintained.

View the Workload

Having created a new workload, the Workloads section of the StackPath Control Portal will display the list of all workloads currently configured.

Selecting a specific Workload will provide more details about what is running.

Monitoring of basic metrics (CPU and memory) is included for no additional cost for every workload. These metrics are collected for each instance from outside the instance itself. No monitoring processes run inside instances themselves, which are entirely under your control through the image provided. Monitoring data is kept for 24 hours. More advanced monitoring will be available in the future.

Newly created workloads

The instance list will be populated within a few seconds of the Workload being created. Initially, the instances will show as Starting. There may be a slight delay before all instances show up in the list.

After a few seconds, the workload will be fully deployed and the full instance list will be shown as Running.

If an anycast IP address was selected for the workload, this will be shown when viewing the workload details.

In order to activate Object Storage, you will need to have an active StackPath account with an Active Stack.

In order to use StackPath Object Storage, you will need to enable it on your existing Stack.

Enable Object Storage on a Stack

If you do not already have any existing services enabled on your account, to use Object Storage you'll first need to create a Stack. You will also need to make sure you have a payment method on file as Object Storage is a pay as you go model. You will not be billed until your next billing cycle and you will only be charged for the GB's used.

Log into the StackPath Control Portal and select an active Stack

SelectObject Storagein the left-hand navigation bar

SelectContinue to enable it on your stack https://docs.aws.amazon.com/cli/latest/reference/s3/rm.html

Your StackPath Object Storage service is now enabled.

Create your first bucket

Now that we have the Object Storage enabled, let's create your first bucket. Simply click the Create Bucket button above and you will be taken to the Create Bucket form.

That's it! Once you click Create your bucket will be created instantly. Buckets are created with Private permissions by default, but if you want to open your bucket up to Public permissions (useful for using with the CDN) you can click Edit and change your Visibility to Public.

Accessing your Bucket

In order to manage the content of your bucket, you will need the AWS CLI tool found at https://docs.aws.amazon.com/cli/latest/userguide/install-bundle.html

Go back to the main Object Storage page by clicking Object Storage in the sidebar

Click the Generate Credentials button below the list of buckets to create your client access key and secret

Click Generate Credentials on the Modal to confirm you want to create a new set of credentials. Once completed, you will want to copy the Access Key and Access Secret to a safe place.Note: Secret's cannot be recovered. If you lose your secret you will have to generate a new one which will destroy the existingSecret.

Now that we have our Access Key and Secret Key we can configure the AWS CLI tool to work with them: In order to access your StackPath Storage buckets with the CLI, you must utilize the configure command.

aws configure

will bring up a series of prompts. Where it calls for the access key and secret access key you will enter youraccess keyand secret key created above. For the region, type "us-east-1". Finally, you can leave the last setting blank.

To access your bucket you will need to append the Endpoint URL provided in the StackPath Control Portal when viewing your bucketto your command. (Example:https://s3.us-east-1.stackpathstorage.com)

The endpoint URL and bucket URL will vary, reflecting the region used to create the bucket.

aws s3 ls --endpoint-url=https://s3.us-east-1.stackpathstorage.com

That's it! You have now configured your AWS CLI tool to have access to your StackPath Storage bucket.

Uploading a file to your Bucket

Now that your AWS CLI tool is configured for your bucket, let's upload your first file!

aws s3 cp /path/to/your/file s3://YOUR_BUCKET_NAME/ --endpoint-url=https://s3.us-east-1.stackpathstorage.com

As you can see the above command works exactly as it does for any S3 compatible bucket. The only difference is we have to add --endpoint-url=https://s3.YOUR-ENDPOINT-URL.stackpathstorage.com to our command so the CLI tool knows where to send the file.

If you want to upload a specific file to your bucket that has public access (even if the bucket is Private) you can append--acl public-read to your command like so:

aws s3 cp /path/to/your/file s3://YOUR_BUCKET_NAME/ --endpoint-url=https://s3.us-east-1.stackpathstorage.com --acl public-read

How to recursively upload a folder to your Bucket

If you have an entire folder or multiple files you want to upload to your Bucket you will need to use the--recursiveflag when cp'ing your files/folders.

aws s3 cp /path/to/your/file s3://YOUR_BUCKET_NAME/ --endpoint-url=https://s3.us-east-1.stackpathstorage.com --recursive

For more details and features around the cp command, please see https://docs.aws.amazon.com/cli/latest/reference/s3/cp.html

How to access Public Files in your Bucket

Once you upload a public file to your bucket, it can be accessed with the following URL:

http(s)://YOUR_BUCKET_NAME.s3.US-BUCKET-LOCATION.stackpathstorage.com/path/to/your/file

Note:The exact URL can always be found in the StackPath Control Portal when viewing your Bucket

Removing files from your bucket

Removing files from your bucket is no different than removing files from S3 using the AWS CLI tool.

aws s3 rm s3://YOUR_BUCKET_NAME/path/to/your/file --endpoint-url=https://s3.us-east-1.stackpathstorage.com

For more details and features around the rm command, please see

That should cover getting started with StackPath Object Storage. As always if you have any questions or need any assistance please do not hesitate to reach out to our 24x7 Live Chat or Helpdesk support.

When using web fonts with @font-face or other CSS3 methods, browsers like Firefox and Internet Explorer may refuse to embed the font when its coming from a third party URL because they perceive the font as a security risk.The recommended way to add it is via the CDN itself. This can be done via the Settings tab of the CDN configuration in your Stackpath Portal.It can take a few moments for settings to propagate on your website after being enabled.

The other way to solve this issue would be on your server itself, by adding a few lines of code.

Apache

Add these lines to the top of your .htaccess file:

# ----------------------------------------------------------------------

# CORS-enabled images (@crossorigin)

# ----------------------------------------------------------------------

# Send CORS headers if browsers request them; enabled by default for images.

# developer.mozilla.org/en/CORS_Enabled_Image

# blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html

# hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/

# wiki.mozilla.org/Security/Reviews/crossoriginAttribute

<IfModule mod_setenvif.c>

<IfModule mod_headers.c>

# mod_headers, y u no match by Content-Type?!

<FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$">

SetEnvIf Origin ":" IS_CORS

Header set Access-Control-Allow-Origin "*" env=IS_CORS

</FilesMatch>

</IfModule>

</IfModule>

# ----------------------------------------------------------------------

# Webfont access

# ----------------------------------------------------------------------

# Allow access from all domains for webfonts.

# Alternatively you could only whitelist your

# subdomains like "subdomain.example.com".

<IfModule mod_headers.c>

<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$">

Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

IIS ver 7.5+

<system.webServer>

<httpProtocol>

<customHeaders>

<add name="access-control-allow-origin" value="*" />

<add name="access-control-allow-headers" value="content-type" />

</customHeaders>

</httpProtocol>

</system.webServer>

IIS ver < 7.5

<system.webServer>

<httpProtocol>

<customHeaders>

<add name="access-control-allow-origin" value="*" />

</customHeaders>

</httpProtocol>

</system.webServer>

Nginx

location ~ \.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$ {

add_header Access-Control-Allow-Origin "*";

}

S3 Bucket

Log in to your Amazon account.

Selectthe S3 Bucket.

Click Edit CORS Configuration.

Add the following code and save all settings:

<CORSConfiguration>

<CORSRule>

<AllowedOrigin>http://www.example1.com</AllowedOrigin>

<AllowedMethod>PUT</AllowedMethod>

<AllowedMethod>POST</AllowedMethod>

<AllowedMethod>DELETE</AllowedMethod>

<AllowedHeader>*</AllowedHeader>

</CORSRule>

</CORSConfiguration>

Frequently Asked Questions

Q: I have added the code but the issue persists. Why? A: If you run curl -I http://origin.com/example-file.woffand confirm there is a CORS header properly added, do the same with a CDN file by running curl -I http://site.company.stackpathdns.com/example-file.woff. If the output is missing the CORS header, purge the CDN cache. This should fix the problem. Q: I am not familiar with system administration. What is the appropriate code for me? A: Different code is needed for each web server. If youre unsure of which web server youre using, run curl -I http://origin.com/and look for the server header. I should contain the name and version of your web server.

To ensure a Site is fully optimized with the StackPath WAF, it's important to ensure the StackPath WAF recognizes all API endpoints correctly. Configuring all API endpoint ensures that users access APIs securely and do not receive browser validation techniques.This article assumes a Site is already configured through the StackPath Control Portal to use the StackPath WAF. If you haven't yet set up WAF for a Site, please view the how-to article here.

For APIs hosted on a separate domain, StackPath will soonlaunch dedicated API protection and acceleration.

WAF Behavioral Adjustments

Adding API URL Endpoint protection completely disables the JavaScript Injection and Captcha functionalities for each API URL path. However, DDoS protection, IP reputation policies, and rate limitation policies will continue to protect the configured API endpoints. It is important to note that custom firewall policies can still impact API URL delivery and potentially block users.

How to add an endpoint

If your web application is using an API that is implemented on the same domain, e.g. www.yoursite.com/restfulapi, then you need to configure it under Sites> Website Domain > WAFand then under theAPI URL Configuration section.

Log into your StackPath Control Portal

Select the Stack the site is located in

Navigate to the Sitestab for your selected Stack and select the site you want to modify

SelectWAF from the top menu bar. The API URL Configuration section is found on this page.

Enter the path of the APIs under your domain you would like to configure.Paths

are recursively allowed. For example, api/allows api/v1/*, api/v2/*, etc.

do not accept regex/wildcard input. For example, useapi/instead ofapi/*

do not include protocol (or domain). For example, useapi/ instead ofhttps://example.foobar.com/api/(the domain is added automatically)

are case insensitive.API/ andapi/ are interchangeable.

require multiple entries for multiple APIs

Changes will be automatically applied, and your API should be accessible. Test your endpoints by performing a cURL on any endpoint to verify that data is retrievable outside of a browser. A 200 server response code should be returned.

If you have any additional questions or concerns, please contact our 24/7 support at [email protected] via live chat.

DNS-based load balancing is the practice of configuring DNS records in such a way that different end users are routed to different servers. StackPath DNS allows you to load balance traffic towards your website, mail server, application server, API or any other kind of publicly accessible network service.

How DNS load balancing works

The main idea behind DNS based load balancing is that the client will target the first IP it receives for a given hostname. When resolving a hostname on StackPath DNS, the list of IP addresses will be returned in a different order each time the new client makes a DNS query. The list of IP addresses for a given DNS record is rotated on a round robin basis. That kind of setup makes different end users routed to different machines, effectively creating a load balancing configuration at a DNS level.

Advantages of DNS load balancing solution The main advantage of DNS load balancing is the ease of configuration. Essentially, the only thing required is multiple DNS records for the same hostname pointed to different IPs of all the machines serving requests for a given web service. Another advantage is the fact there is no new software to install and no additional server configuration changes to make - the traffic is routed at a DNS level.

Drawbacks of DNS load balancing solution

While DNS based load balancing is fairly easy to set up, it comes with a few inherent drawbacks. DNS itself is not capable of monitoring the servers for potential load issues or any kind of network outages. If one of the servers gets overloaded or becomes inaccessible due to a network outage, itwon'tbe automatically taken out of the rotation and the end users would still be routed to it since theres no way for the DNS to know the machine is experiencing issues. Once the issue is discovered, taking the machine in question out of the rotation might take a while since DNS changes are not always instantaneous. That problem can be partially tackled by setting up lower TTL values for the DNS records, but the clients and intermediate DNS resolvers might still have old DNS records cached for extended periods of time.

Example: Setting up DNS load balancing for a web service

In order to implement DNS load balancing for a web service (e.g. a website or an API endpoint), the A records for the hostname in question need to be pointed to all IPs of the machines serving requests for a given web service. For example, if requests for api.mywebsite.com hostname are served by 3 different machines, each having their own IP, three separate A records for api.mywebsite.com need to be set up in StackPath portal, where each A record is pointed to a different IP address of the target machines. Once the DNS changes are propagated, every new end user will be routed to a different IP address and the DNS load balancing setup is complete at that point.

For example, one client will get a response for 1.2.3.4, 1.2.3.5 and 1.2.3.6 IPs and will be routed to the first IP. The second client will get a response for 1.2.3.5, 1.2.3.6 and 1.2.3.4 IPs (in that order) and will be routed to 1.2.3.5 IP address instead. However, it is important to keep in mind that not all operating systems will have the same behavior and some clients might ignore the first IP in the response they receive and route the request to a second or a third IP address instead. Generally, that shouldnt be a concern since the majority of end users will exercise the standard behavior of targeting the first IP in the response.

Example: Setting up DNS load balancing for a mail server

StackPath DNS can also be used for load balancing traffic for a mail server. There are 2 approaches to implementing DNS load balancing for a mail server. The first and most common approach is to assign the same priority (usually a priority of 10) to all MX records for a given domain. That way, the SMTP server resolving to the domain in question will get all MX records in a different order every time a request is made, and most SMTP servers will target the first record in a response, similar to the scenario described in a previous section.

For example, there are 3 MX records for mail.mywebsite.com, each pointed to different mail server:

The second option is to create multiple A records for the same mail server hostname and point each one of them to different IPs of the target mail server machines. Afterward, a single MX record with a priority of 10 (which is the most common priority assigned to MX records) is created and pointed to the IPs of target mail server.

For example:

If you have any further questions, please contact our 24x7 Support team through live chat or a ticket.

The Browser Cache Time To Live (TTL) is the amount of time the end-users browser will cache a resource. This resource will be served from browser local cache until the TTL expires, after which the browser will request the asset again.

Overview

When an end-user visits a website, the users' browser downloads the static content (images, etc.) of the website so that it may be displayed to the end-user. This content is stored in browser local cache for a certain amount of time, specified by the "max-age" value of the origin server's Cache-Control header. When the contents max-age is reached, it is purged from the browser local cache on the user's computer and will need to be fetched from the website's origin (or CDN if cached) the next time the user browses to the site. TheBrowser Cache TTL function within StackPath's portal allows administrators to set abrowser expiration time for cached assets that don't already have an expiration time set on the origin server. Please note that the CDN will follow the origin's Cache-Control headers if present.The default value set within the StackPath portal for Browser Cache TTL is 1 hour. This value may be adjusted based on the needs of the website. If the static content of the website is changed or updated frequently, then a low TTL is recommended, however, if the static content does not change often then a much longer TTL can be used.

Cache-Control headers take precedence over Expires headers when both are present. If your website is being flagged for "Add Expires Headers", don't worry! They're antiquated, as Cache-Control headers have primarily replaced them.

How To Change Browser Cache TTL

Log into the StackPath Control Portal

Navigate toSites > Domain > CDN

Browser Cache TTL is located under theClient Browser Policy section. Use the dropdown box to select the desired TTL for browser-cached assets.

If a site is being flagged by speed tests for "Serve static assets with an efficient cache policy", try extending the browser cache TTL first!

Verifying The Header

To verify that the desired browser cache TTL has been applied, the response headers from a cached static asset can be checked. One of the response headers from the asset will be "Cache-Control", with the max-age set at the time specified in the portal for the browser cache TTL (in seconds). The following image shows a static asset that is being served directly from the origin server:

Notice the absence of the Cache-Control header. Now, we will activate the CDN and display the response headers for the same asset, with the browser cache TTL set to 1 hour (3600 Seconds):

If any clarification or assistance is needed involving browser cache TTL, or any other settings within the StackPath portal, please reach out to us in support chat or drop us a line at [email protected].

The built-in Magento rewriting module also rewrites static HTML pages. This is great for performance, but browser security policies require additional headers to be passed over the CDN in order for HTML pages to be loaded over the StackPath CDN.

StackPath EdgeRules allow you to create robust custom rules to modify the behavior of the StackPath CDN. If you have not already, please check this guide to get started.

Creating the Rule

Select the CDN Site you would like to create the rule for

Navigate to theEdgeRules tab

Select Add Delivery Rule

In the IF section, add *://cdn.url/* as the URL Matches Option for this rule. Remember to replace cdn.url with the actual Edge Address, or custom Delivery Domain.

In the THEN Section, add a response header rule to add Access-Control-Allow-Headers: x-requested-with.

It is possible to apply this rule to any number of file types by prefixing them with a ? to indicate a wildcard location, and | to separate them. For example, the rule /\.(?.pdf|htm?l|jpe?g|gif)$/ will apply to pdf, html, jpg, jpeg, and gif files.

Verifying the Rule

Since this rule adds a public response header to the CDN Response, it is possible to verify it by checking the headers from your CDN assets using browser inspect tools or cURL requests.

For browser tools, you canright-clickanywhere on your website and selectinspectorinspect element and navigate to thenetworktab. If you do not see any requests, you can refresh the page with this tab open to view them as they come in.

Select an asset served from the CDN from this tab to reveal the headers associated with the request. The Access-Control header should appear here.

When performing a cURL test, the option -I is recommended, to show the headers appropriately. Below is an example of a curl, with the Access-Control header highlighted.

If you have any questions or would like any assistance setting up this rule, feel free to open up a chat with our 24/7 live support, we'll be happy to help you out.

A robots.txt file improves SEO by instructing search engine crawlers to which pages theycancrawl and index. This EdgeRule will redirect any request to the StackPath CDN for a robots.txt to the file that is stored on the origin server.

If you have not already, please check this guide to get started.

Creating the Rule

Navigate to Sites and select the CDN Site you would like to create the rule for

Navigate to yourEdgeRules tab

SelectAdd Delivery Rule

In the IF section, select the URL Option, with the Matches modifier and pastein*://*/robots.txt

In the THEN section select theRedirect rule and add inhttps://%client.request.host%/robots.txt.Please include the full path to the robots.txt file.

The initial IF statement declares that any request for "robots.txt" will trigger this rule. The %client.request.host% in the DO section is an accepted variable that will use the information in the HOST request header sent by the end-user. This can be replaced with the domain, if you would prefer, or if these would be separate values. Remember to include the appropriate file path for your robots.txt file!

Verifying the Rule

This rule adds a public response header to the CDN Response. Verify this EdgeRule by checking the headers from CDN assets using the browser inspect tools or cURL requests.

For browser tools, right-clickanywhere on your website and selectinspectorinspect element and navigate to thenetworktab. If you do not see any requests, refresh the page with this tab open to view them as they come in.

The initial request for your robots.txt should result with a 301 Permanent redirection, and lead to the new URL specified by the rule.

When performing a cURL test, the option -IL is preferred, to follow any redirection links and to see the headers appropriately. Below is an example of a curl, with the 301 response and location of the new robots.txt file.

If you have any questions or would like any assistance setting up this rule, feel free to open up a chat with our 24/7 live support, we'll be happy to help you out.

If you are using a CMS or custom CDN implementation that is not included in the CDN no-cache rules, you may desire to apply a rule to prevent the CDN from caching specific files or paths. This article will walk through the process of setting up a custom rule to do just this.

If you have not already, please check this guide to get started.

Creating the Rule

Navigate to Sites and select the CDN Site you would like to create the rule for

Navigate to yourEdgeRules tab

SelectAdd Delivery Rule

In the IF section, select the URL Option, with the Matchesmodifier, and paste in *://edge.address/ followed by the directory or file you would like to exclude from cache. (edge.address can be replaced with your Edge Address or by one your Delivery Domains)

In the THEN section select theDo Not Cacherule to to remove the cache-control header and instruct the CDN to avoid caching the assets.

Adding the AND HTTP Mehtodoption is optional in this case. But in the above example, this will apply the rule only to POST requests to this website's administrative page.

Verifying the Rule

Since this rule modifies a public response header to the CDN Response, verify the new EdgeRule by checking the headers from any CDN asset using browser inspect tools or cURL requests.

For browser tools,right-clickanywhere on the website and selectinspectorinspect element and navigate to thenetworktab. If no request is seen, refresh the page with this tab open to view them as they come in.

Check the request for the matching file or directory to ensure they are excluded from cache.

Before implementing the EdgeRule, there is a cache-control header specifying the TTL for the file, and the CDN has cached the file, as indicated by the .cat the end of x-hw response.

After implementing the EdgeRule, the cache-control header is removed, and the CDN will no longer cache the file, indicated by the .p at the end of the .p at the end of the x-hw response.

When performing a cURL test, the option -I should be used to see the headers appropriately. Below is an example of a curl, where the x-hw header shows the asset was not cached.

curl -I https://c7j8f9a6.stackpathcdn.com/js/jquery/jquery.js?ver=1.12.4HTTP/2 200date: Thu, 20 Dec 2018 17:06:27 GMTcontent-length: 97184content-type: application/javascriptlast-modified: Tue, 21 Aug 2018 19:29:33 GMTserver: Apacheetag: "17ba0-573f70ba995a3"accept-ranges: bytesvary: Accept-Encodingaccess-control-allow-origin: *x-hw: 1545325587.cds087.da2.hn,1545325587.cds030.da2.sc,1545325587.cds030.da2.p

If you have any questions or would like any assistance setting up this rule, feel free to open up a chat with our 24/7 live support, we'll be happy to help you out.

This rule will apply a custom request header to the CDN requests toward your origin server. It can be used as a check for specific browsing habits or confirmation that a request was made by the CDN for troubleshooting purposes.

If you have not already, please check this guide to get started.

Creating the Rule

Select the CDN Site you would like to create the rule for

Navigate to theEdgeRules tab

SelectAdd Delivery Rule

In the IF section, add aMatchesoption for the Edge Address (or any Delivery Domain)

In the THEN section, add the desired request header. The StackPath CDN will apply the header directly to any requests made by the CDN toward the origin server.

Apply this rule to any number of file types by prefixing them with a ? to indicate a wildcard location, and | to separate them. For Example, the rule /\.(?.pdf|htm?l|jpe?g|gif)$/ will apply to pdf, html, jpg, jpeg, and gif files.

Verifying the Rule

This rule does not add any publicly accessible headers or redirects and will need to be confirmed through checking the access logs on the origin server. Please consult your hosting provider for the appropriate steps to view these.

If you have any questions or would like assistance creating this rule, feel free to contact our 24/7 live support.

This EdgeRule is used to redirect mobile devices to mobile websites, in a Full Site Integration situation.Every request made to the internet will include a "User-Agent" header that identifies the device sending the request. StackPath can use this information to adjust the response, based on the contents of this header.

If you have not already, please check this guide to get started.

Creating the Rule

Select a Site you would like to create the rule for, this Site will need CDN Enabled

Navigate to yourEdgeRules tab

SelectAdd Delivery Rule

In the IF section, add a Header Regex Matchesoption to/User-Agent: *(iPhone|Android).*/to catch mobile users.

In the THEN sectionadd a Redirect Rule with the value ofhttps://m.yourmobiledomain.com.Remember to replace m.yourmobiledomain.com with your actual mobile connection subdomain.

The Regex Matches option defined above will match any User-Agent Header that includes iPhone or Android and redirect to m.yourmobiledomain.com. It is important to keep in mind that this match is case-sensitive and will only work if the incoming User-Agent matches the casing as defined in the rule. Please remember to replace the redirect link with the actual domain you use for the mobile version of your website.

Verifying the Rule

This rule can be validated by a cURL command with the -A option applying a custom user-agent header to the request, triggering the rule as if it were a mobile user.

If you have any questions or would like any assistance setting up this rule, feel free to open up a chat with our 24/7 live support, we'll be happy to help you out.

StackPath offers custom Delivery Rules with every Site configured for CDN. EdgeRules provide users a great amount of flexibility to customize the behavior of the StackPath CDN. EdgeRules trigger upon receiving a request that matches the rules' specific conditions.

EdgeRules occur only on CDN requests, the EdgeRule response is added before the request is processed by the StackPath WAF, so every CDN EdgeRule will work in tandem to the WAF if both are in use.

Creating Custom EdgeRules

1. Log in to the StackPath control panel. EdgeRule Presets

2. Navigate to the Site the EdgeRule will be created for.

3. Select the EdgeRules tab

4. Within this tab, the Delivery Rules section will be where custom EdgeRules for the CDN will be created. Select Add Delivery Rule to create a custom rule.

5. You will be prompted to define your EdgeRule with dropdowns for Conditions and Rules Options (as defined below).

Conditions

Conditionsare requirements that trigger EdgeRules to activate.The initial Condition will begin with an IF statement, and any subsequent conditions will be added with AND statements. The rule will only trigger if all specified conditions are met.URL: The rule will trigger if the requested URL matches what is specified in this section. This also includes any specified file-paths or file types.Header: The rule will trigger if there is any request header sent to the CDN that matches the specified header typed into the field.HTTP Method: The rule will trigger if there is a request for the specified method. All common HTTP methods are acceptedStatus Code: If the CDN receives the specified status code from the origin, the CDN will apply the rule.

Rules Options

Rulesdefine the action that the StackPath EdgeRule will action once the conditions trigger.

Add Response Header: Will add a custom response header to the CDN response, as specified.Add Header to Origin: Will add a custom Request Header to the Origin.Cache: Will set the Cache TTL for the response to the specified TTL. The Cache-Control header will be updated to reflect this new TTL.Do Not Cache: Will apply a no-cache rule to the specified response and will add a no-cache value to the Cache-Control header.Never Expire: Will remove the TTL from the specified response and allow the asset to be cached indefinitely.Redirect: Will create a permanent 301 redirection towards the specified URL.Hide Header Will remove the specified header from the CDN response header listModify HeaderWill change the value of the specified response header when sent by the CDNSign URLWill set up basic URL signing for the specified request

URL Filters

It's possible to use wildcards, regex and globbing in your Custom EdgeRules to create patterns that match specific URLs allowing you to create a CDN configuration to your specific requirements.

Here are some examples of options for these filters:

Pattern

Description

Example Matches

wildcard: http://*

Only HTTP requests

http://abcdef12.stackpathcdn.com/index.html

wildcard: https://*

Only HTTPs requests

https://abcdef12.stackpathcdn.com/index.html

wildcard: *://foo.com/*

HTTP/HTTPs request for foo.com HostName

http://foo.com/index.html, https://foo.com/static/js/anydirORfile

wildcard: *://*.html

Any request for HTML files

http://abcdef12.stackpathcdn.com/index.html, https://example.com/index.html

wildcard: !*://*.txt

Any request except TXT files

http://abcdef12.stackpathcdn.com/index.html, https://example.com/static/img/index.jpg

wildcard: *://.html,*://*.js

Any HTML file or JS files

http://abcdef12.stackpathcdn.com/index.html, https://example.com/static/js/jquery.js

wildcard: !*://*.txt,!*://*.jpg

Any request except TXT and JPG files

http://abcdef12.stackpathcdn.com/index.html, https://example.com/static/img/index.jpg

wildcard: *://abcdef12.stackpathcdn.com/static/*.html

Any request for HTML file under Directory (recursive) "static"

http://abcdef12.stackpathcdn.com/static/index.html http://abcdef12.stackpathcdn.com/static/foo.html http://abcdef12.stackpathcdn.com/static/2/index.html http://abcdef12.stackpathcdn.com/static/2/st/index.html

glob: *://abcdef12.stackpathcdn.com/static/*.html

Any request for HTML file under Directory (one level) "static"

http://abcdef12.stackpathcdn.com/static/index.html, https://abcdef12.stackpathcdn.com/static/foo.html

regex: /.*\d/index.html/

HTTP/HTTPs request for index.html under directory of Numbers

http://abcdef12.stackpathcdn.com/static/1/index.html, https://abcdef12.stackpathcdn.com/static/20/100/index.html

Please note that if you specify the protocol in your pattern this will be ignored once the file has been cached by the CDN.

For example, patternhttp://example.com/jquery.js, then any requests tohttps://example.com/jquery.jswill be proxied. However, once a request tohttp://example.com/jquery.jshas been made,jquery.js will be cached and a cached response will be returned for subsequent requeststohttps://example.com/jquery.js.

Validating and Troubleshooting EdgeRules

Most custom EdgeRules will apply an external change, such as a visible response header or redirect, which makes troubleshooting EdgeRules simple using either Curl requests in a terminal or within a browser using the network tools.

For Curls, the -I option to display headers is the most vital in verifying the rules, to check if the custom header or redirect was applied correctly. Demonstrated below is an example response from the User-Agent Redirection example. With a specified user-agent option attached to the Curl with the -A Option to specify an iPhone is trying to connect.

Browsers can also be used for verifying the behavior of a given EdgeRule. The following example is taken from a rule that just a "test" header to validate the rule has triggered. Any of the specified headers and response code based on the responses will be viewable.

Common EdgeRule Use Cases

Adding a Canonical Header

Excluding Content from CDN Cache

Adding an Access-Control Header for Magento 2.x

Redirection by User-Agent

If you have any questions or would like further assistance with EdgeRules, our support team is available for 24/7 live chat.

The guide will assume that you already have a StackPath Object Storage bucket setup and are ready to connect that bucket to the StackPath CDN. If you do not already have a bucket created, check out our Getting Started with Object Storage page.

StackPath's Object Storage service enables customers to store, manage, and serve files remotely without the need for a personally managed server. Adding the StackPath CDN service in front of an Object Storage Bucket enables substantially quicker retrieval times on frequently accessed files and guarantees no matter where you access your bucket from, pull times experience the full benefit of the StackPath network.

StackPath does not charge for egress from Object Storage or ingress for CDN, which means all content retrievals from StackPath Object Storage to the CDN are free of charge. Please note that delivery from the CDN to end-users will count toward your CDN bandwidth allocation.

Configuring your Bucket

Bucket URLs are case sensitive. If a bucket has any uppercase letters, be sure to remain consistent with these in your Host header and Origin Address.

To enable use with CDN, WAF, or EdgeEngine, Object Storage buckets must be configured for public access. Further restraints can be placed on your bucket with EdgeRules like URL Signing or IP Whitelist/Blacklist.

Navigate to the Bucket by selecting Object Storage from the left-hand navigation bar.

The fourth column in the bucket list is Visibilityand it specifies Private or Public. Every bucket is provisioned by default with Visibility set to Private.

If the bucket is already public, proceed to the next step. Otherwise, select Edit, Change the Visibility state to Publicand Save your changes.

Now that the bucket is publicly available, the Site created during the next step have the needed access. For the next step, save the Bucket URL for the bucket.

Create your Site

The next step in this process is to create a Site that will connect to the Object Storage bucket as the Site Origin. Please make sure you have the Bucket URL available.

Select Sites > Create Site

Enter the Domain you would like StackPath to serve content under, and select the services you would like to use. StackPath's Object Storage can work with any or all of CDN, WAF, and EdgeEngine.

Find the Bucket URL under Object Storage > Select the bucket > Bucket URL > Copy

Paste the StackPath Bucket URL in the Hostname/IP address field when creating a CDN Site

Once the Site has been created successfully select Continue.

The site will deploy with a Host Header that matches the Domain entered in step 2. Since the Object Storage expects a particular Host Header, be sure to change this before proceeding. Under your Site > Settings > Origin > Host Header click Add New

Change the Host Header to the StackPath Bucket URL

Congratulations, your StackPath bucket content is now accessible over HTTP or HTTPS from your Site's Edge Address. Assets placed in Object Storage can be pulled and cached on the CDN from your Bucket, using edge-address/path/to/object.

For any questions related to StackPath Object Storage Buckets, please contact our 24x7 support team via chat or through [email protected].

What is compression?

Compression is the process of taking a file and reducing its size. There are many methods through which this is accomplished, but the method utilized by gzip takes advantage of the fact that many files have long sequences of data that are exactly the same. For example, a data file might contain 8 bytes in a row of the binary value "1" (0000001). This sequence of bytes can be represented symbolically in one byte with the value "8" (00001000), thus reducing the size of the file by a factor of 8.

The algorithms used by gzip and other compression utilities are far more complex than explained above and are able to utilize numerous other statistical quirks to achieve even greater compression levels.

What Gzip level does Stackpath support?

Currently, gzip supports compression up to level 9, with the default being level 6.

Stackpath will compress content to levels 1 to 6 because higher compression levels offer significantly diminishing returns for the effort required to reduce files by this much.

How is Gzip used by the CDN?

Modern browsers are capable of fetching files in a compressed format and uncompressing them on the fly, which reduces the amount of data the end-user must fetch from the server when loading a web page. This can lead to significant performance gains in site load time.

The Stackpath CDN is capable of fetching uncompressed assets from the origin, compressing them in cache (up to level 6), and serving them in compressed gzip format to browsers that advertise they are capable of handling compressed assets.

You can update the gzip compression setting by logging into the StackPath control portal, selecting a CDN site, navigating to Settings and locating the Cache Settings section, in which you will find the gzip compression option. Click the button to enable and then choose your desired compression level from the dropdown that appears below.

Once compression has been enabled on a site, all assets matching the policy will be compressed in cacheafter they are ingested again from the origin.

Assets already in cache when the policy is enabled will not be compressed, so it is important to purge the host after the policy is applied to ensure that the assets are compressed.

Another important note is that if an asset needs to be compressed but is not already in cache, the CDN will fetch the asset from the origin and proxy it to the user immediately in a compressed format while queuing the asset for compression in the background.

What if files are Gzipped on my Origin?

Assets that are already in .gzip format (or any other compressed format) on the origin will be treated as normal assets and served straight to the end-user without any in-cache processing. If compression levels 7 through 9 are required, the assets must be compressed by the Origin before being uploaded to StackPath.

When enabled, are all files Gzipped instantly?

Files already in cache before the compression policy was enabled will not be compressed until they are ingested from the origin again (Purging the file(s) is a great way to accomplish this).

If you'd like to read more about gzip compression we'd like to recommend this article:https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/

The StackPath control panel allows users to change the primary account email address of the actively logged in user.

To start, navigate to https://stackpath.com/ and click login at the top right of thebrowser.

Sign in then navigate to your contact information by clicking on your name in the top right corner of your browser window and choosing Profile from the drop-down menu in the top right corner. [email protected]

You will be taken automatically to the Contact information section of your profile where you can find and update information like your email, password, phone number. Select theemail field. Remove the email address currently associated with your account and type a new one in, for the purposes of this document we will use as our new email.

For security, you will be prompted to enter your current password below the new email address. Type your password in and click the blue save changes button.

Thats it! If you received a green success message at the top of your browser you have successfully updated your information!

ShortPixel Adaptive Images is a free, easy to use WordPress image optimization plugin that specializes in compressionand provides the ability to resize, re-scale, and serve images in their original file format or in the next-gen WebP format.

There are two integration options when integrating ShortPixel AI with StackPath:

Full Site Integration

This is the recommended method and caches all site files on the StackPath CDN. A plugin is used to deliver images using ShortPixel.

Static Assets Integration

This integration method involves using a plugin to rewrite static asset URLs with the StackPath Edge Address. The ShortPixel CDN is used to serve a limited number of free images per month.

This tutorial assumes that the steps have been followed to create an initial StackPath Site. The differences between site integration options are discussed in this article.

Preparation

The steps in preparing for the use of ShortPixel are the same regardless of which integration option is chosen.

To use ShortPixel AI to optimize and serve images, follow the steps below:

Log into your WordPress admin panel. generate a free SSL certificate

Select Plugins from the left menu and click Add New.

In the Search box, type "ShortPixel Adaptive Images" and click Search Plugins.

Click Install Now, and then activate the plugin after the installation completes.

Create an account with Shortpixel

Connect your domain with your Shortpixel account.

Upload your images to your Shortpixel account.

Using ShortPixel AI In A Full Site Integration

Full site integrationsprovide a method of using StackPaths CDN to optimize and serve a websites images, or assets only integration, which requires that ShortPixel AIs CDN is used to do so. Performing a full site integration is recommended for SEO, security, while also taking the load off your server, and reduces DNS lookups.In order to use the plugin with a full site integration, a second StackPath CDN Site will be created to optimize and serve the images. This is an ideal scenario for those who want to take advantage of automatic image resizing, serving images in the next-gen WebP format and automatic compression of served images without having to do the manual work typically involved in doing so.

Note: This section assumes that a full site integration is already in place for the root domain.

If the website is full site integrated, then we can utilize a subdomain to serve the ShortPixel-optimized images from via the StackPath CDN. To do so, follow the steps below.

Log into your StackPath Control Portal.

Click the Create Site button.

Create a Domain Name for the subdomain from which the ShortPixel AI images will be served from. Tick the CDN box under available services.

Set the Hostname/IP Address to 176.9.21.54.

After successfully creating the CDN site for the subdomain, navigate to the Settings tab on the top menu bar. Change the host header to the actual website's URL (if the root domain serving your website is https://example.com, change the host header to example.com).

Click the EdgeSSL tab located on the left, you will need to upload your own SSL certificates that covers this domain, generate a free SSL certificate or use the StackPath wildcard SSL cert

Copy the EdgeAddress that was generated for this site located in the top right of the portal.

Navigate to the website's managed DNS page (if using StackPath's, this will be done by clicking the DNS tab on the left menu bar). Create a CNAME record for the subdomain created to serve the images, and point this to the EdgeAddress you just copied.

Log in to the WordPress admin panel for the website.

Navigate to the ShortPixel AI settings by hovering over the Settings tab on the left menu bar and selecting ShortPixel AI.

Click on the Advanced tab at the top. In the API URL text box, enter the URL for the subdomain used to serve the ShortPixel images, and append /spai to the end of it, then click Save Changes.

Now ShortPixel will scan the website for all images, optimize them to the selected settings and serve them over the created subdomain.

Using ShortPixel AI In A Static Assets Integration

Note: this section already assumes that there is a static assets integration already in place for the root domain

Log into your StackPath account.

Select the CDN Site that ShortPixel will be serving images for.

Select the Settings tab on the top menu bar, and under the Origin menu, click Edit next to the Address text field that shows the origin server's IP address. Change this field to 176.9.21.54.

Confirm that the Host Header field is filled with the website's URL.

Click the CDN tab on the top menu bar. Under Cache Handling, change the settings to reflect the following image:

Click the EdgeSSL tab located on the left, you will need to upload your own SSL certificates that covers this domain, or use the StackPath wildcard SSL cert

Images on the website will now be optimized and served via ShortPixel AI's image CDN. Take note that with this setup, 100 images per month can be served via the ShortPixel AI CDN before you must purchase a plan to continue serving images over their image CDN.

If any assistance or clarity can be provided during the setup to connect your StachPath account with ShortPixel AI, please do not hesitate to ask in support chat, available 24/7 or through [email protected].

The StackPath CDN and WAF make a powerful combination for fast, reliable content delivery that provides protection from application threats. This article is a walkthrough for configuring these two services and assumes A StackPath account is created and a Stack combination has been selected that includes CDN and WAF services.

There are two options for integrating the StackPath's CDN. This article, utilizes a Full Site delivery method which is achieved through modifying DNS records and is required for use of the StackPath WAF.

About this Integration

The integration process will work with any subdomains for the primary domain but has been written with the common WWW subdomain in mind primarily. If a separate custom subdomain (blog orinfo) is desired, simply replace any instance of WWW with the custom subdomain.

This integration will involve adjusting DNS records for full site acceleration and protection, the StackPath DNS is recommended, but this is not a required service for this integration.

Add the Domain

Sites can be created with CDN and WAF enabled simultaneously by choosing the Create Site button:

If a standalone Site is already setup, you can simply enable CDN or WAF from the Overview Tab for that Site.

Log into the StackPath Control Portal

Navigate to theStack Overview page, and select Create Site Pingdom Tools

Enter the domain name for the integration

Select theCDNandWAF checkboxes (along with any other services desired)

SelectContinue

Confirm the Origin server data is correct and selectContinue again

This will generate the Site for the domain entered in Step 2 along with an Edge Address for the Site.

Configure Site Origin Settings

Before any DNS records are adjusted, it is best practice to confirm the proper configuration, to avoid any website downtime after the DNS records are adjusted.

Origin Configuration

To avoid any network errors while trying to reach the website through StackPath's systems, please confirm the following information within the Site settings for this domain before proceeding with the integration:

Origin Address: This should contain the IP address of the origin server.

Host Header: This field contains the value for the host request header StackPath will send to the origin server, this should be the primary version of the domain to be used. If the website has a redirect in place to force WWW connections, the WWW subdomain should be used in this field.

Origin Pull Protocol:This should match the HTTP version used by the website. If redirection is enabled for HTTPS enabled on the origin, please set this option to HTTPS Only.

Delivery Domains: TheApex domain and WWW subdomain should be added by default, but please add both if they are not present, along with any other subdomains intend to use with StackPath.

EdgeSSL Settings

If the website uses HTTPS, please ensure an SSL certificate is uploaded or complete the validation process for the free EdgeSSL certificate, provided by StackPath. Free EdgeSSL validation will be completed automatically if DNS is already migrated to StackPath.

EdgeRules

If HTTPS or WWW redirects are being utilized on the origin server these can be enabled within the EdgeRules tab under Sites > Website Domain > EdgeRules

Configure WAF Settings

The WAF settings will be configured next. We will start with whitelisting IP addresses in the Allowed IPs section. Adding these will prevent false positives from occurring when administrators are working on the site.

Add any administrative users' public IP addresses to the WAF Whitelist in theFirewalltab.

if a CMS is being used, enable the Protection policy for the applicable CMS and whitelist the Origin IP.

Allow Known Bots as applicable.

Origin Security

The final step before integration will be to check any security plugins or firewalls enabled at the origin level to ensure the StackPath IP blocks are whitelisted to prevent any issues with StackPath systems connecting to the origin.

Adjusting DNS Records - Go Live

With all of the preparation complete, the final step is to adjust DNS records to resolve the domain(s) to StackPath. This can be done via StackPath DNS (if the nameservers were already migrated); or via the current DNS provider, if not using StackPath DNS. This process will vary based on the DNS provider.

Adjust the record for the WWW subdomain to be a CNAME Record that resolves to the Edge Address provided. The WWW subdomain would look similar to this when using the StackPath DNS.

It is also recommended to point the apex domain to the anycast IP of the Edge Address in order to protect the real server IP from being discovered.

This step should be completed with an ANAME record or through Domain Shortening if offered by your DNS provider, as StackPath's anycast IP is subject to change at any time.

Verify the CDN is Integrated Properly

Once DNS propagation is completed, this integration can be verified with a specific DIG request for the records that were created previously. This article provides instructions for integration verification.

Test Speed and SEO Post Integration

At this time, please perform another speed test by using Google Page Speed and.

Compare the before and after tests and note that it can take one to seven days for a website to reflect the performance improvements of a CDN. Both of these test sites also will give SEO recommendations.

Secure Socket Layer (SSL) is a form of encryption that uses Certificate Authorities to validate a safe connection between systems. At StackPath, you can upload your own SSL certificates to use custom URLs instead of the Edge Address provided to you. Sometimes, however, these certificates are provided in an encrypted form, that needs to be converted to a format you can upload.

This article will walk a user through the process of converting a .pfx file to a .crt and .key file so that the SSL certificate can be uploaded into the StackPath Portal.

A.pfxfile is a PKCS#12 archive : a file that can contain a lot of objects with optional password protection; but, usually, a PKCS#12 archive has a certificate (possibly with its assorted set of CA certificates) attached to it andthe corresponding private key.

That's how .crt or .cer files differ from .pfx files - they contain a single certificate file, without any keys attached.

The StackPath portal requires that you upload the certificate and key in their separate corresponding fields and this is how you can extract them from your .pfx file.

Navigate to the terminal of your operating system and execute the following commands to extract the files:

Certificate:

openssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [certificate.crt]

Key:

openssl rsa -in [keyfile-encrypted.key] -out [keyfile-decrypted.key]

These two commands will generate two separate files which you can later use in your Stackpath SSL configuration.

In this guide, we'll introduce how to use Flask, Waitress, and Docker to create a web service Living on the Edge. Our goal is to create a web application that accepts an HTTP request and returns a UUID in the body, with the geographic location of your compute container also returned in an extra header, implemented in pure python.

Note: Here we will use Docker, a popular package for building and deploying containers, though any container image that adheres to the OCI specification can be deployed onto Edge Computing.

Before we get started, let's make sure you have a few basic requirements out of the way.

You should have:

Docker installed on your machine

Python with virtualenv installed

A repository to host docker images (DockerHub or Docker server)

Basic Components of the Application

Dockerfile: Configuration file that instructs the runtime how to build your container

requirements.txt: A list of python dependencies needed to run our code.

.dockerignore: Files to ignore when building the container image

app.py: Python script to respond to HTTP requests to the container

Create a Working Directory

To keep our project organized we will create a new directory for this project and change into this directory. Subsequent commands in this tutorial will be executed from this directory unless otherwise stated.

$ mkdir flask_uuid

$ cd flask_uuid

Create your VirtualEnv

So that we don't pollute the system python with the project dependencies we will use a virtual environment to execute code in when testing. Virtual Environments allow you to install multiple python modules that may otherwise conflict on the same system and allows you to maintain discrete environments for each python project you are working on. We'll create one now so that we can ensure we have the correct dependencies for our flask application.

$ virtualenv venv

The virtual environment will be created which will include a new python executable at the pathvenv/bin/python.We can call python with this path, but it's simpler to just execute python. Let's activate our virtual env so that our $PATH is updated and we're only using the virtual env instance of python.

$ source venv/bin/activate

Once you've activated your virtual environment you'll see your terminal prompt change to include the virtual environment name (which in this example is venv)

(venv)$

Install Requirements

Now we have a virtual environment setup for testing lets install the requirements for our flask project. We have two requirements, flask and waitress. Create a text file named requirements.txt and add the following to it:

Flask==1.0.2

waitress==1.2.1

Once that file is saved, install the requirements inside the virtual env (remember, your prompt will update with the virtual env name to let you know that you are inside the virtual environment).

(venv)$ pip install -r requirements.txt

You may notice that extra modules were installed too, that's because flask is dependant on other python modules to be able to run and pip has satisfied these dependencies automatically.

Serve Requests

Now we have our development environment setup we can start to create our flask web application and respond to HTTP requests.

Create a file named app.py and add the following to it, this code is commented so that you can understand what is happening.

from flask import Flask # import the flask module we installed earlier

import uuid # import the uuid module, this ships with python so we didn't need to install it

app = Flask(__name__) # Initialise the flask app as app

@app.route('/') # Declare the '/' route for app using a route decorator

def get_uuid(): # Define a function to respond to the route

return str(uuid.uuid4()) # Return a uuid string as the response

That's all we need! We can now start the development server and confirm that our application responds as we expect. Start the development server with

(venv)$ FLASK_APP=app.py flask run

And you'll see the following output

(venv)$ FLASK_APP=app.py flask run

* Serving Flask app "app.py"

* Environment: production

WARNING: Do not use the development server in a production environment.

Use a production WSGI server instead.

* Debug mode: off

* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

Our application is being served on port 5000 using the development server. You can now load http://127.0.0.1:5000/ in a web browser to get a uuid! Python Base Image on Docker Hub

Add Response Headers

Perhaps in the future, you will want to debug your application but you need to know which location is serving your request to allow you to troubleshoot further. In this instance, it would be helpful to return the container location in a response header. You can use the hostname environment variable to determine where the container is deployed and we can return this in a header in our response.

To add the location to an SP-LOCATION header update your app.py to the following, additions have been highlighted in green.

from flask import Flask

import uuid

import os

import re

app = Flask(__name__)

@app.after_request

def add_hostname_header(response):

env_host = str(os.environ.get('HOSTNAME'))

hostname = re.findall('[a-z]{3}-\d$', env_host)

if hostname:

response.headers["SP-LOCATION"] = hostname

return response

@app.route('/')

def get_uuid():

return str(uuid.uuid4())

We've added a add_hostname_header function which checks if the env variable HOSTNAME is present and that a simple regex search of the hostname can return the three-letter location name and the container number from the end of the hostname string. If these evaluate to true, we add the result of the regex to the SP-LOCATION header.

Serve Requests with Python

Now we need to enable a web server to manage and handle the requests we receive. Flask ships with a development server, however, this is not suitable for production. Instead, we'll use Waitress, which is meant to be a production quality pure python WSGI web server. We've already installed the waitress module so we simply need to add it to our code. Update your app.py file to the following:

from flask import Flask

from waitress import serve

import uuid

import os

import re

app = Flask(__name__)

@app.after_request

def add_hostname_header(response):

env_host = str(os.environ.get('HOSTNAME'))

hostname = re.findall('[a-z]{3}-\d$', env_host)

if hostname:

response.headers["SP-LOCATION"] = hostname

return response

@app.route('/')

def get_uuid():

return str(uuid.uuid4())

if __name__ == "__main__":

serve(app, listen='*:80')

We've added the waitress import and instructed waitress to serve the application, listening on port 80 on both IPv4 and IPv6 when this module is executed directly. Let's double check that this works locally before we wrap this up in a docker container.

As we've added waitress in, we need to use a different, simpler command to run the server, and we'll be shown the ports and addresses that waitress is listening on:

(venv)$ python app.py

Serving on http://[::]:80

Serving on http://0.0.0.0:80

We can also test by loading http://localhost in a browser. (We don't need to specify a port to the browser here as port 80 is the default for HTTP).

Create a Dockerfile

Now we're going to create a container for this application so we can deploy it to the edge. Create a file called 'Dockerfile' (no extension) with the following contents:

FROM python:3-alpine

WORKDIR /usr/src/flask_uuid

COPY . .

RUN pip install --no-cache-dir -r requirements.txt

CMD ["python","app.py"]

For those unfamiliar with dockerfiles, a brief explanation is below:

The python:3-alpine image is used as a base. The alpine image is used as it is extremely small and lightweight and we do not have complex dependencies.

The WORKDIR is set to/usr/src/flask_uuid

The contents of the build context (the current dir which contains the Dockerfile) are copied to the WORKDIR in the container

pip install is executed against the requirements file, installing our dependencies.

The command for the container is set, which in our instance runs our Flask app served by waitress.

Let's also create a .dockerignore file so we don't copy unrequired items to our container

Dockerfile

.dockerignore

.git

.cache

venv/

*.pyc

Now we're ready to build our container.

$ docker build -t <your name>/flask_uuid .

You can view your built container with:

$ docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

<your_repo>/flask_uuid latest 418a87009dad 3 hours ago 33MB

Deploy your Image locally

First, let's run our docker image locally to determine if it works as we expect.

$ docker run -p 49160:80 -d <your_repo>/flask_uuid

This command aliases port 80 on our container instance to port 49160 on our local machine. Access 0.0.0.0:49160 in the browser

We can also test with curl too

Notice how the SP-LOCATION header we defined is not there? That's because the hostname env variable is either a) not present, or b) the application was not able to parse the hostname with the provided regex. Once this is deployed to the Edge you will see this header.

Run docker ps to display active containers

$ docker ps

Let's shut down the container

$ docker stop <container id>

Now that we've confirmed the Docker image built successfully, let's deploy the script onto Edge Computing.

Push the new docker image by its repository name to your DockerHub or personal docker repository.

$ docker push <your_repo>/flask_uuid

Now your docker image is publicly accessible and Edge Computing can pull and deploy it.

Deploy your image on Edge Computing

Add a new Workload

Add a Name and add your image, including the repository that you pushed your Docker image to in the Image field. Select the Wordload type: Container.

Next you can add environment variables, however we don't need any for this project. Enable the Anycast IP option to be provisioned one IP address that will respond from the closest edge, where you code is deployed, to the user.

Now we can select the VPC (currently only default is available), the required public ports and if we want to execute a command in the container. We don't need to add any commands as the command we need is already in the Dockerfile, so we'll add port 80 to allow web traffic to our container.

Select the spec you require for your containers and add the locations you require

Check and confirm your cost estimate, then click 'Deploy Workload' to have your code deployed to your chosen edge locations.

Congratulations, your flask web application has been deployed! In less than a minute StackPath will partition IP addresses to your Pod and the web application will be live and available for your use.

Use the Application

Now it's deployed, test that your code behaves as you expect. Load your IP in a browser to get a UUID.

With cURL, check that the header has been added:

You can also test the header is correct for each location by cURL-ing each container IP instead of the Anycast IP address.

External Links

Documentation for Docker, Flask, VirtualEnv, and Waitress is available in case you would like to develop this project further.

Docker Documentation

Flask Documentation

VirtualEnv Documentation

Waitress Documentation

When a new StackPath Edge Computing container is created, one or many environment variables can be specified. These are key/value pairs which are made available to all instances running in the Workload.

Environment variables are used to set configuration values that are defined at runtime or deploy, rather than embedded within a container image.

For example, you might have an application which accesses a 3rd party API that requires credentials to authenticate. Good security practice is that credentials are not stored within the image, but provided at runtime through environment variables. This allows for easy credential rotation, avoids leaking credentials as part of the image and restricts access only to those who might need them.

Setting Environment Variables

Environment variable key/value pairs can be set when creating the workload. For example, in the StackPath Control Portal UI:

chat

Accessing Environment Variables

When you set a variable during workload creation, each becomes available within all instances running in the workload. You can access these environment variables programmatically in most languages by pulling the variables from the os or process a given program is running in.

To list these variables in terminal ssh into your container.

You can list all variables in the current session using the standard command printenv.

To list all system wide variables use the standard command set.

Below is an example of pulling the two system variables set previously in this article.

If you have any additional question or concerns please feel free to reach out to our 24x7 Support team via and we will be happy to help.

An SSH key is required to deploy any StackPath VM. This guide will walk you through how to generate one from your local computer that can later be added to all deployed services.

SSH access allows you to connect to your instances securely without having to manage credentials for multiple instances. Multiple SSH Keys can be added to StackPath Workloads to allow more than one user to connect and manage the VM.

Before adding an SSH Key to the workload, we need to ensure that we have one available to use. If you already have an SSH Key you can skip ahead to Adding SSH Keys to Your Workload.

Linux / MacOS

Check for Existing Keys

First, let's check that there are not already keys present and available for use. Open a terminal and execute the following to list all files in your .ssh directory that start with id_

ls ~/.ssh/id_*

If you see no output, or "No such file or directory" then you do not have any keys present and you need to proceed to the next step. If you see an output similar to the following, then you already have SSH keys:

$ ls ~/.ssh/id_*

/Users/user/.ssh/id_rsa /Users/user/.ssh/id_rsa.pub

You can either skip to 'Adding SSH Keys to Your Workload', or you can create a new key for StackPath EdgeCompute instances. If you're creating a new key for EdgeCompute instances we recommend that you backup your current keys now.

Creating A New Key

To generate a new key, simply execute the following from your terminal, updating the comment to either your email, or another comment that will allow you to easily identify the key at a later date: ssh-keygen -t rsa -C "[email protected]" This will output the following response, seeking confirmation on the location to save the key: [email protected]

Press the Enter key to accept the default (~/.ssh/id_rsa).

You'll then be prompted for a passphrase. Enter your desired passphrase and confirm with the Enter key. You'll need to do this twice to confirm the passphrase is correct. Once you've entered your passphrase your key will be generated and you'll see an output similar to below:

Congratulations! You've just created an SSH key and are half way to adding the key and SSHing to your instances!

Windows

Check for Existing Keys

First, let's check that there are not already keys present and available for use. Open a command prompt and execute the following to list all files in your .ssh directory that start with id_

dir "%userprofile%\.ssh\id_*"

If you see no output, or "No such file or directory" then you do not have any keys present and you need to proceed to the next step. If you see an output similar to the following, then you already have SSH keys:

C:\Users\User>dir "%userprofile%\.ssh\id_*"Directory of C:\Users\User\.ssh03/21/2019 01:03 PM 1,766 id_rsa 03/21/2019 01:03 PM 401 id_rsa.pub 2 File(s) 2,167 bytes 0 Dir(s) 16,978,898,944 bytes free

You can either skip to 'Adding SSH Keys to Your Workload', or you can create a new key for StackPath EdgeCompute instances. If you're creating a new key for EdgeCompute instances we recommend that you backup your current keys now.

Creating A New Key

To generate a new key, simply execute the following from your terminal, updating the comment to either your email, or another comment that will allow you to easily identify the key at a later date:

ssh-keygen -t rsa -C "[email protected]"

This will output the following response, seeking confirmation on the location to save the key:Press the Enter key to accept the default (%userprofile%\.ssh\id_rsa).

You'll then be prompted for a passphrase. Enter your desired passphrase and confirm with the Enter key. You'll need to do this twice to confirm the passphrase is correct. Once you've entered your passphrase your key will be generated and you'll see an output similar to below:

Congratulations! You've just created an SSH key and are on the way to adding the key and SSHing to your instances!

Add to a VM Workload

Now that you have created an SSH key pair, the public key must be added to a remote machine to SSH into. The SSH host machine (your local computer) will use its private key to encrypt the connection, while the remote machine will use the public key to decrypt the connection.

To SSH into a VM Workload, the remote VM must have the following setup:

SSH configured Port open to incoming connections (Default 22)

Your ssh public key in the remote machine's ~/.ssh/authorized_keys file

Configure through the Portal

In Public Ports open the Default SSH port on your VM and add your id_rsa.pub to the SSH key field. Multiple keys can be entered by separating each with a linebreak.

Upon creation, your VM will be deployed with the firewall open to connections on Port 22. The public SSH key will be uploaded to the VM's Authorized Keys file exactly as entered in the StackPath portal.

If you have any additional questions or concerns, feel free to reach out to StackPath Support via or over our 24/7 live chat.

Global anycast IP addresses allow traffic to be routed to the nearest StackPath Edge Computing Edge Location, reducing latency and response times for application users.

What is Anycast?

Traffic directed to the anycast IP will enter the StackPath Network at the closest Edge Location, and will then be routed to the nearest location where the workload has instances running. Traffic will be balanced across all instances running in that location but there is no guarantee that this will be even across all instances. This means the anycast IP acts as a pseudo-load balancer, considering both the regional latency of the closest edge to the traffic source as well as spreading traffic across all running instances. At present, this routing logic is non-configurable, has no balance guarantee and there is no advanced balancing logic involved. Future plans include more advanced load balancing functionality.

Example 1: If a Workload is deployed with instances running in Dallas and London, and a visitor makes a request to the anycast IP from London, their traffic will enter the StackPath network in London and hit the instances running in London.Example 2: If a Workload is deployed with instances running in Dallas only, and a visitor makes a request to the anycast IP from London, their traffic will enter the StackPath Network in London and will then be routed over the StackPath private backbone to hit the instances running in Dallas.

Anycast IPs are billable resources, charged for the duration that they are allocated to a workload.

The IP will be released when the workload is deleted. It is not currently possible to reserve IPs which means that deleting and recreating a workload will usually mean a different IP address will be allocated.

Adding an Anycast IP address

When creating a new Workload, there is an option to add a global anycast IP address.

chat

Ticking this option will allocate an anycast IP address to the workload. All instances will still have their own individual ephemeral IPs allocated but in addition, the anycast IP can be used to route traffic to the entire workload.Anycast IPs can currently only be allocated when a workload is created, not afterward - this will change in the future. The IP will be static for the lifetime of the workload.

If you have any additional questions or concerns please feel free to reach out to our 24x7 Support team via and we will be happy to help.

URL Signing protects CDN assets by ensuring only authorized end users are able to access them. URL signing can be used to set an expiration time on a given URL, verify the URL was requested by the same IP address it was issued to, or only allow certain user agents to access your URLs. CDN assets with URL signing enabled will use an MD5 hash appended to the URL which validates access should be granted.

This rule can also be configured with more options via the StackPath API.

Add the Custom Rule

Log into the StackPath Control Portal and navigate to Sites Website Domain Edge Rules. Unix Epoch time of expiration

Select "Add Delivery Rule" under the Delivery Rules section.

Depending on the desired implementation of URL Signing, it can be set up to work for the entire site or for only certain file types. In this example, URL Signing will be configured for the playlist with an extension of .m3u8. To match all playlist files, please use *://*.m3u8

On this page, there are four fields to configure.

Passphrase - The secret key used to generate the hashed value used to sign the URL

Passphrase Field - The URL parameter field that identifies the passphrase pre-hashing

MD5 Token Field - The URL Parameter field that identifies the post-hash token

TTL Field (Optional) - The URL Parameter that defines the Time To Live value to be hashed

IP Address Allowed List (Optional) - A comma-separated list of IP addresses allowed to view the signed content.

Assembly of a Signed URL

Once configured, here is how the Signed URL is assembled:

Take everything after the apex of the domain (/path/to/playlist.m3u8) and add the passphrase field and passphrase as a query string. For example:

/path/to/playlist.m3u8?passphrasefield=passphrase123

Generate an md5 sum using the full file path of the desired asset

echo -n "/path/to/playlist.m3u8?passphrasefield=passphrase123" | md5

output: 23b18cd9d9cc16e03fe3b94deb3a7894

Append the md5 sum as a query string '?' defined by your token field. In the above example, the final product becomes:

https://yourdomain.com/path/to/playlist.m3u8?StackPath=23b18cd9d9cc16e03fe3b94deb3a7894

Including a TTL Field

The URL signing rule includes an optional TTL Field to specify a time for asset expiration. Using this setting will create the URL Parameter for the value to be defined when generating the md5 sum and used for the final request.

The TTL must be defined by the and included in both the pre-hash and post-hash URLs.

Append a newly defined TTL value and everything else defined above to the appropriate query string; using the above example this becomes:

/path/to/playlist.m3u8?expires=1542810073&passphrasefield=passphrase123

(At the time of this article,1542810073 is epoch time plus one day)

Generate the md5 sum using this full file path.

echo -n "/path/to/playlist.m3u8?expires=1542810073&passphrasefield=passphrase123" | md5output: 3fa69bc7d3678d7a500b57a31a433522

Append the TTL field, including the epoch time of expiry as a query string, along with the token field and hashed token for validation:

https://yourdomain.com/path/to/playlist.m3u8?expires=1542810073&StackPath=3fa69bc7d3678d7a500b57a31a433522

Code Examples

Bash

Mac:

echo -n "/path/to/playlist.m3u8?passphrasefield=passphrase123" | md5

Other Linux:

echo -n "/path/to/playlist.m3u8?passphrasefield=passphrase123" | md5sum

Python3

import hashlib### Variables set in control.stackpath.compassphrasefield = "passphrasefield"passphrase = "passphrase123"tokenfield = "StackPath"### Variables from your applicationurl = "/path/to/playlist.m3u8"completeurl = url + "?" + passphrasefield + "=" + passphraseprint(url + "?" + tokenfield + "=" + hashlib.md5(completeurl.encode('utf-8')).hexdigest())

StackPath features the option to set a backup CDN origin to serve assets if your primary origin becomes unavailable. The backup origin provides an extra layer of protection when a primary server fails to respond for any reason.

How does it work?

The primaryorigin fails over to backup if the CDN cannot connect or find the requested file, for any reason. Every request is handled on a case-by-case basis, that is, the CDN will not stop sending requests to the primary origin based on failover history.

Types of responses that trigger failover

Connection Timeout

DNS errors & unresponsiveness

4XX

All Client Errors

5XX

All Server Errors

When requests are proxied to an Origin from the CDN, StackPath analyzes the response code of each request todeterminehow to handle the response. The following steps track a request in a full cycle, from end-user request to end-user response.

An end-user requests an asset and requests resolve to StackPath CDN

The CDN approves the request and sends an additional request out to the primary origin.

A site's primary origin returns a 5XX, a 4XX, or the connection times out.

This response triggers the backup origin policy. The CDN will attempt to open a connection with your backup server and request the same file path from the alternate host.

If the given file path exists on the backup Origin, the CDN will pull and cache this content.

If it does not, the response code from the backuporigin will be forwarded to the end user.

If the content is cachable, the CDN will cache the backup origin content and no longer proxy to either origin.

The CDN returns to the state of Step 1. Each subsequent request goes through Step 1 to 7 until the primary origin recovers.

Backup Requests

When a request hits the primary origin, and the response fails, a second identical request is sent to the backup origin. No information derived from the first request is included in the backup request, and likewise, no additional headers indicating a mishap are sent to the client.

Request structure

The CDN sends two similar requests to the primary or backup origin. Each request sent to the primary or secondary origin differs only by a host header for serverside authentication. Due to this behavior, it's important to mirror the primary origin's structure directly onto the backup origin. Variance in file paths may lead to unexpected File not found errors.

Primary Path:https://{primary_server.com}/folder/content/images/image005.jpg

Backup Pathhttps://{backup_origin.com}/folder/content/images/image005.jpg

Backup Responses

From the end-user perspective, the backup response should not change as compared to an origin response. Although users are subject to varying amounts of latency when a failover occurs, no supplemental information is added by the CDN in the body or headers of the response.

Latency

The latency for requests that respond with 5XX errors is substantially longer than those that are triggered by 4XX errors. When dealing with 5XX response codes, the CDN must wait for a primary origin to timeout before proxying the request to a backup origin. Under normal circumstances, 4XX response codes resolve much quicker and are often imperceptible.

Backup Caching

Any assetpulled from a backup origin can be served while the primary origin is on or offline, which allows the CDN to fetch, cache, and serve content even when something unexpected goes wrong. The cache for a site is shared between the primary and backup origin, so the backup origin's content can seamlessly fill a primary origin's shortcoming.When a request to a primary origin fails, two things happen. Requests are immediately proxied to the backup and the CDN caches all approved uncached content for future requests. This behavior prevents performance bottlenecking, even when an origin is out of commission.

After primary origin recovery:

When the CDN caches a webpage, response headers for each request are cached with it. After the primary origin recovers, we recommend purging the cache to revalidate all content and ensure it is up to date. Shown below; it is possible after a primary origin failure to have cached content from both the primary and backup origin.

StackPath Control Panel

Setting up a Backup origin

Configuring a backup origin in the StackPath control panel is as simple as entering the secondary origin address in CDN origin Settings. Verify that the backup origin can receive and serve incoming requests from the StackPath CDN, just as a primary origin can.

Login to the

Navigate to Sites> Website Domain > Settings. Backup is listed under the Origin heading. Flip the switch to On

This opens a text box for the IP address for the backup server, you can type that in, or paste it in here and selectSave.

To test the Backup Origin, you can temporarily switch your backup origin to your primary origin and purge all cache. If the backup origin works as a primary origin, the CDN will be able to pull all requested files from your backup.

Congratulations, your backup origin is now protecting your site from primary origin downtime.

If you have any additional questions or concerns, please contact StackPath via 24/7 live chat.