Do you have any sample images of these configurations on CloudFront? /_hcms/*, /hs/*, /hubfs/*, /hs-fs/*, /cs/c/*, and /e3t/*.
thanks
Hey @nahsupasawat , you should be able to apply a wild card in your Behavior path pattern in Cloudfront - All distribution settings reference - Amazon CloudFront
Regarding step 6, domain validation, what happens if a CNAME record cannot be added because it is already in use? We had our domain validated by Hubspot via HTTP challenge and now in the reverse proxy verification we get that it fails checking Delegated Domain Control Validation (DCVs). We received also a message saying that the reverse proxy would stop working unless we fix that.
@aitortomas - the domain validation steps provide a CNAME and TXT record that are not used for serving content and are in place for a one time (and potentially on-going) validation check. The CNAME you need to update is for the subdomain _acme-challenge.[subdomain] - you may already have an entry for this in your DNS zone, but all you need to do is update the CNAME value to a new record. You’re not adding/altering the subdomain and CNAME of the actual content hosting domain (that is connected to your proxy).
- Navigate to the HubSpot domains tool & find your proxied domain
- Select Actions > Show DNS Records
- Copy subdomain & CNAME value, add/edit those values in your DNS zone
- After propagation, navigate back to HubSpot domains and ‘verify reverse proxy connection’
@robertainslie we already have the CNAME pointing to Fastly for the subdomain (www) as the subdomain is not only for the marketing pages. We already set up the reverse proxy and have some pages live in Hubspot in that www subdomain but with the recent changes, the subdomain validation that was done via HTTP challenge with Hubspot tech support is no longer valid it seems. Maybe I am missing something (quite probably) but I believe it is not possible to have multiple CNAME pointing to Fastly and Cloudflare.
Hey @aitortomas , Yea - I think the misunderstanding is that the CNAME update that is required is for the DCV not for the traffic routing and is not asking you to update where your proxy is pointing.
What does not need to change:
- Your www points to your proxy server or CDN (Fastly)
- Fastly routes traffic to multiple origins, one of those origins is a CNAME record like {hubID}.sites-proxy.hscoscdn40.net - this actually hosts the content
What does need to change:
- In the past, to prove domain ownership you could have followed an HTTP challenge or you could have updated your DNS with a TXT record that looked like Record: “cf-custom-hostname.mulligandevelopment.io” Value: “655f6c48-bd6a-4d2f-88a2-d5c4ef5070d7” as well as a CNAME like Record host: _ca3-0bf93ffdd5b24db6b793475620821cb3.tc; Value: dcv.digicert.com.
- Now, you need to create a NEW DNS CNAME record to control the DCV process that will look like this: Record host: _acme-challenge.rp Value: rp.robertpainslie.com.07e5b8acaef7b01e.dcv.cloudflare.com
- You very likely do not already have a CNAME record at the host of this new “acme_challenge” host and if you DO, then you can update the value to be this new CNAME host pointing at the cloudflare.com value.
- The values are provided to you
Once you’ve added the DNS record for the “acme_challenge” CNAME, then you run the verification in HubSpot.
Does that help clear things up? Feel free to DM me any screenshots of your setup if things aren’t clear. Also, if you provide your HubID I may be able to take a look at your Domains Manager and confirm what records you need.
Also - this should be a process that HubSpot Support can help you with identify the right records in order to prove DCV ownership for your domain - open up a chat/email or call with them. They won’t be able to help with your proxy itself, but if you highlight that you need to understand what DNS records are needed to prove domain ownership, they should be able to help with that.
Apology for this question in this time of years.
I am trying out to setup reverse proxy between hubspot enterprise sandbox + nginx reverse proxy.
so our main domain is `example.com` and we are want to use link our subdomain to hubspot, let say it is `www.cms.example.com `. I have setup our nginx config like this
location ~ ^(/hs|/_hcms|/hubfs|/hs-fs|/cs/c) {
proxy_pass https://xxx.sites-proxy.hscoscdn10.net;
proxy_pass_request_headers on;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-HubSpot-Client-IP $proxy_protocol_addr;
proxy_set_header X-HubSpot-Trust-Forwarded-For true;
proxy_set_header X-Real-IP $proxy_protocol_addr;
proxy_set_header Host $host;
proxy_set_header X-HS-Public-Host www.cms.example.com;
proxy_ssl_server_name on;
}
On hubspot verification, i can see that there is a request coming in and we are getting error like
"GET /_hcms/status HTTP/1.1" 421 171 "-" "HubSpot Connect 2.0 (http://dev.hubspot.com/) (namespace: chase.redirect.http.client) - CosDomainsWeb-userweb" "143.244.87.71,10.160.11.37"
I am trying to figure out what I missed and I hope someone can leave hints or guides on what should I do to get more info and pinpoint what is going on
Thanks in advance and happy holiday 
Hello,
Is the `X-HS-Public-Host` header case sensitive? My domains keep saying they are disconnected from Hubspot, even though Hubspot is serving content from those domains. My users are unable to add content to the affected domains.
The only way my configuration differs from the docs, and from suggestions in this post, is that my `X-HS-Public-Host` header is all lower case. Cloudfront functions and Lamda edge functions, both result in a lower-case `x-hs-public-host` header.
I’m looking for support on getting location-personalized content to work with a reverse proxy. We’ve had a reverse proxy set up for HubSpot for a while, but location-based content is not working correctly. We include the X-HubSpot-Trust-Forwarded-For: true header, and looking at the /_hcms/diagnostics page for our hosted page, the Effective IP is the desired client IP for location-based content.
These are the diagnostics results; I’ve redacted some of the information.
Current time: 2025-02-19T20:51:57.398Z
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Accept-Language: en
Accept-Encoding: gzip, br
Cookie: <not present>
Protocol: https
X-Client-IP: <not present>
True-Client-IP:{NAT gateway IP}
X-Real-IP: {NAT gateway IP}
X-Forwarded-For: 212.53.203.31, ...other IPs,{NAT gateway IP}
X-HubSpot-Trust-Forwarded-For: true
x-hs-public-host: <not present>
Edge-Determined Country: US
Edge-Determined Device Type: desktop
Effective IP: 212.53.203.31
Effective IP Source: X-Forwarded-For
IP-Determined Country: de
IP-Determined Region: hamburg
IP-Determined City: hamburg
IP-Determined Organization: artfiles new media
Host: ***.com
X-Forwarded-Host: ***.com
Despite the Effective IP and IP-Determined Country displaying correctly, location-based features are still not working. I see the Edge-Determined Country is still US like our gateway address. Could this be the source of the contents’ determined country?
This is contradictory to the documentation that indicates that personalized-location content should work when the X-Forwarded-For IP is trusted. https://developers.hubspot.com/docs/guides/cms/content/performance/reverse-proxy-support#:~:text=content%20based%20on-,location,-works%2C%20pass%20a
Would appreciate any ideas from someone who’s seen a similar issue or knows which value actually powers HubSpot location features.
@robertainslie is there any documention for setting it up using Azure FrontDoor or Azure Application Gateway. We are having issues setting it up in FrontDoor.