English (US) Deutsch Español (España) Français (France) 日本語 한국어 Português do Brasil 简体中文

Cloudflare Help Center

Get help with Cloudflare products

Detailed system status >

Articles in this section

Connect with the Cloudflare Community

Get answers

Automatic Signed Exchanges (SXGs)

  • Updated

Learn more about Signed HTTP Exchanges (SXGs)

Overview

SXGs is still a Beta product. Keep this in mind before enabling it for your zone(s). If you experience any problems, disable SXGs and let us know.

Automatic Signed Exchanges (SXGs) are an open, standard delivery mechanism that makes it possible to authenticate the origin of a resource, independent of how it was delivered. This enables faster delivery of a website from a third party — such as Google itself from its search results page — or from a news aggregator that is linking out to other sites. This decoupling enables a variety of use cases, such as prefetching, offline Internet experiences, and serving from third-party caches. It does so in a secure and privacy-preserving manner, and Cloudflare automatically handles all packaging and certificate handling.

For more details regarding how SXGs work, please check out the announcement blog post. 

What are the requirements for enabling SXGs?

Signed Exchanges have a few requirements:

  • SXGs are available for zones with a Pro or higher plan. SXGs are also available for zones on a Free plan with an APO subscription.
  • SXGs only works with zones that have their nameservers managed by Cloudflare. Learn here how to change your domain nameservers to Cloudflare. After enabling your nameservers to be managed by Cloudflare, log in to the Cloudflare dashboard, select your domain and go to DNS. In Proxy status, enable the Cloudflare proxy in any relevant DNS records by clicking the grey clouds. When proxied through Cloudflare, the cloud will be orange.
nameservers managed by Cloudflare
  • Zone certificates need to be managed by Cloudflare.
    • Note: To obtain an SXG certificate, you need to add a CAA Record for issuance of the certificate from the Certificate Authority. Cloudflare adds the corresponding CAA records in DNS on behalf of users after they enable SXGs, to make sure issuance is not blocked. If you would like to obtain SSL certificates that are issued by other CAs, please ensure that you add the CAA records for the CAs after enabling the SXG.
  • Content needs to be cached in intervals of 120 seconds or longer, as Google checks this setting to generate an SXG. To ensure that content is cached every two minutes or more, go to the Cloudflare dashboard > Caching > Configuration > Browser Cache TTL and check the length of time Cloudflare instructs a browser to cache files.
  • AMP Real URL needs to be disabled if SXGs is enabled. To do that, go to the Cloudflare dashboard > Speed > Optimization > AMP Real URL and click the toggle to disable this setting.

How to enable SXGs

If your account satisfies the requirements to enable SGXs:

  1. Log in to the Cloudflare dashboard and select your account and domain.
  2. Go to Speed > Optimization.
  3. Scroll down to Automatic Signed Exchanges (SXGs) and toggle the button to enable it.

Limitations

  • Currently, signed exchanges are only used by Google for Android search. Google is working on implementing support for SXGs on desktop browsers.
  • Google only loads Signed Exchanges for the top results.
  • Signed exchanges can strip out certain cookies and headers, and create problems with dynamic content. The following hop-by-hop and other uncached headers will be stripped during the signed exchange generation:
    • Hop-by-hop header fields listed in the Connection header field (section 6.1 of RFC7230).
    • Header fields listed in the no-cache response directive in the Cache-Control header field (section 5.2.2.2 of RFC7234).
    • Header fields defined as hop-by-hop:
      • Connection
      • Keep-Alive
      • Proxy-Connection Trailer
      • Transfer-Encoding
      • Upgrade
  • Since Cloudflare cannot be sure whether a signed exchange includes private information or not, a signed exchange will not be generated in the presence of the following headers:
    • Authentication-Control
    • Authentication-Info
    • Clear-Site-Data
    • Optional-WWW-Authenticate
    • Proxy-Authenticate
    • Proxy-Authentication-Info
    • Public-Key-Pins
    • Sec-WebSocket-Accept
    • Set-Cookie
    • Set-Cookie2
    • SetProfile
    • Vary
    • WWW-Authenticate

FAQ

There are a couple of ways to ensure that SXGs are working properly for your zone:

Method 1:

1. Run the following command in your terminal:

curl -svo /dev/null https://example.com -H "Accept: application/signed-exchange;v=b3"

2. Verify that the Content-Type is set to application/signed-exchange;v=b3.

Method 2:

  1. On a desktop computer, open Chrome.
  2. Go to View > Developer > Developer Tools.
  3. Click the Toggle device toolbar button, and select an Android device.
  4. Click the Network tab in Chrome’s developer tools.
  5. With the Network tab open, search Google for your zone plus your website. For example, yourdomain.com + website.
  6. Refer to the Network tab in Chrome’s dev tools. In the Type column you should see the result with signed-exchange / Redirect.

Method 3:

  1. Log in to your Google Search Console account.
  2. Conduct a Mobile Usability URL Live Inspection for a URL link on your site.
  3. Click More Info > HTTP Response.
  4. If content-encoding: mi-sha256-03 is displayed, it means the SXGs is working properly for your zone.

  1. For a list of tools that you can use to debug SXG, please refer to web.dev's guide to SXG tools.
  2. If it’s an AMP page, you can refer to the AMP status report — Search Console Help, which explains the impact using SXGs has on AMP pages.
  3. For non-AMP cases, or non-AMP SXGs customers, there isn’t yet a help page which would describe the error type breakdown. However, if there are any critical errors that would warrant disabling the SXGs:
    1. You should be able to detect them for a specific URL by following the steps in Verify SXG Setup.
    2. They should show up later in the Search Console as "Fetch errors". Refer to Monitor and debug SXG for more information.
  4. To ensure that Googlebot is able to crawl and index a page served by SXG, take these steps:
    1. Verify that the Content-Type is set to application/signed-exchange;v=b3.
    2. Run the command dump-signedexchange and make sure it finishes without errors.
    3. Check that the signed URL matches the request URL.

No. Google can still parse the signed exchange and treat it like normal HTML. In the case of an AMP page, Google should fall back to treat it like it would treat a regular AMP page.

We use Digicert for SXGs certificate issuance. Once SXGs is enabled, we add the CAA records on behalf of the zones:

% dig example.com caa
;; ANSWER SECTION:
example.com.		XXXX	IN	CAA	0 issue "digicert.com; cansignhttpexchanges=yes"
example.com.		XXXX	IN	CAA	0 issuewild "digicert.com; cansignhttpexchanges=yes"

To obtain an SXG certificate, you need to add a CAA Record for issuance of the certificate from the Certificate Authority. Cloudflare adds the corresponding CAA records in DNS on behalf of users after they enable SXGs, to make sure issuance is not blocked. If you would like to obtain SSL certificates that are issued by other CAs, please ensure that you add the CAA records for the CAs after enabling the SXG.

No. This is for an unreleased/in-development feature. It’s safe to block those requests, and  users can ignore them.

Related resources

Not finding what you need?

Submit a request

Related articles

Not finding what you need?

Submit a request