I’m using Netlify Functions (node 10) and would like access to the Host header or X-Forwarded-Host.
Netlify seems to strip this header, is this intentional and is there a workaround?


I’m having the same issue and asked a similar question here Knowing the current public hostname of a Netlify function

We provide an X-Bb-IP header you can use instead of X-forwarded-For (which I think is the header name you meant - please tell me what you are trying to achieve, if not!). Those other two names will not work reliably as we use them internally (you’d see something like

This doesn’t answer your question, @pixelastic - sorry I don’t know the answer but I think my more function-savvy colleagues will be able to help you out with that next week.

Thanks for your feedback @fool I should have explained my use case. I’m trying to provide different functionality in my function based on the subdomain similar to @pixelastic requirements.

Normally you would receive a host header or when running behind a proxy a x-forwarded-host header.

These are not present in Netlify’s functions.

Hi @dalejefferson_rnf. I don’t think we will add the X-forwarded-host header but should pass it on if it exists in the original request. Could you confirm that your original request has it?

Thanks for the reply @Dennis

This is the behavior i’m seeing.

  1. Netlify removes the host header
  2. Netlify does not add a X-Forwared-Host header
  3. If you include a X-Forwared-Host header (Run netlify behind a reverse proxy) Netlify removes this header

I just did a simple curl and inspected the headers to confirm 3.

curl -v -H “host: example.com” -H “X-Forwarded-Host: example.comhttps://example.com

I just need some way of knowing what the hostname is. :upside_down_face:

What i’m trying to achieve is.

site1.example.com => netlify function outputs site1
site2.example.com => netlify function outputs site2
siten.example.com => netlify function outputs siten

Ideally where I can have any number of sites (wildcard subdomain)

Are these subdomains hosted on the same netlify site that your functions are on? If so, would this work?

    headers = {Custom-Header = "site1"}

You’ll need to add each subdomain as a domain alias to your netlify site and a redirect for each subdomain.

Yes they are hosted on the same netlify site so that workaround is something we are considering but would not allow for the siten scenario (wildcard). We would have to do a deploy to add a new site (Unless you can modify headers without deploying?).

Yea, that (the wildcard scenario) won’t be possible, I don’t think. A new deploy would be needed to add a new subdomain.

Thanks for the confirmation @Dennis

My understanding is that Netlify already supports wildcard domains, the bit I’m missing is knowing which subdomain invoked the function. Is this likely to be supported in a future release (adding a HOST or X-Forwarded-Host header)?

I can look at using the workaround for the time being but it would be great to have an indication that Netlify would be looking at adding this feature as it’s a deal-breaker for our use of Netlify long term.

Hi, @dalejefferson_rnf. Is Dennis’ answer here helpful?

@luke That’s exactly what I need, I’ve just tested it and it works great.

The only question I have is can I rely on this, is this public API that I can have some level of assurance that will not change or not change wither prior warning?

You’re referring to the Netlify API?


We definitely have no intentions of breaking changes without warnings - but you might also take at the github repository and subscribe there if you have concerns.

@perry I taking about the context.clientContext.custom.netlify attribute passed to a function as mentioned by @luke unless I missed it this is not publicly documented and I’m worried it may change without warning.

"context": {
    "callbackWaitsForEmptyEventLoop": true,
    "functionVersion": "$LATEST",
    "functionName": "kjdkfjdkjfkdj",
    "memoryLimitInMB": "1024",
    "logGroupName": "/aws/lambda/4jfdkjfdkjhfdjhdfj",
    "logStreamName": "2020/01/21/[$LATEST]fdfkjdkfjdkfjkdj",
    "clientContext": {
        "custom": {
            "netlify": "eyJzaXRlX3VybCI6Imh0dHBzOi8vYXBwLmJlYW0tY29tbWVyY2UuY29tIn0="
    "invokedFunctionArn": "arn:aws:lambda:eu-west-2:554605863837:function:fdjkfdhjkdfhjjfdhjdfhdf",
    "awsRequestId": "dkfhjdkhfkdhjfhfd"

No breaking changes are intended there either.

However, we base our implementation entirely on the AWS lambda implementation and API and so are limited by what they (continue to) support. Here’s an example of a “well that’s gone suddenly” that we had to react to recently, though it is not really adjacent to the functionality you are talking about:

I also see you are providing a client-ip header - is this a header you are supporting long term?

No. Please use X-NF-Client-Connection-Ip which will work for the foreseeable future.

Hi @fool, can you provide any example to attach the origin ip with x-nf-client-connection-ip in header in netlify.toml ?
I tried to find an example but can’t find any.

netlify.toml has no relation to that header and it will not be usable there. It is available only when your visitor runs a function, and then you access it in the standard way you access HTTP request headers in your framework of choice.