HTTP_CF_CONNECTING_IP changed when using Functions

Hi.

Our site at app . example . com has previously had a Worker that rewrites all requests to /api so that the requests instead goes to api . example . com in order to avoid CORS requests.

A few weeks ago we changed this to use a _middleware Function instead like below:

export const onRequest: PagesFunction = async ({ request, next }) => {
    // If an API call then rewrite URL to API
    const url = new URL(request.url);
    if (url.pathname.startsWith('/api/')) {
        url.host = "api . example . com";
        return fetch(new Request(url, request));
    }
....

The problem is that when we did that, api . example . com receives the HTTP_CF_CONNECTING_IP which now always contains the same IP for every request - namely a Cloudflare IP.

Any idea why and if we can do anything about It?

“In cross-zone subrequests from one Cloudflare customer zone to another Cloudflare customer zone, the CF-Connecting-IP value will be set to the Worker client IP address '2a06:98c0:3600::103' for security reasons.”

Thanks, so what does this really mean? Why did this not happen when doing it with a standard Worker? And - any way to get by this?

You should be able to read the CF-Connecting-IP in the first worker and then add your own header to pass this IP on to the sub-request target.

Thanks, but there should only be one and only one function / worker running now (the above _middleware which is the only function we have in the functions folder). The previous Worker is now inactive (or the route for it has been disabled). Is there anything else being acted as a “first worker”?

We have a _headers file as well - could it be that those together work as a “cross-zone” request?

It doesn’t need to connect to another worker, just another Cloudflare destination (in this case, your API subdomain).

I have a simple worker that fetches webpages and returns them, those sites are passed this IP if querying one of my sites that is also on Cloudflare. The same shows up in the WAF (the Cloudflare IP but with the original IP’s ASN).

Okay. Ain’t it very strange then that this has been working for years when using the exact same code but in a Worker? :slight_smile: Or maybe that was running at the same zone as api _ example _ com then! That could be it right?

So, you say that in my Functions code I will have the correct ip in CF-Connecting-IP and then set a new header with this IP?

I believe so, as long as you don’t have any users calling your API with a worker! Should be easy to give it a quick try.

1 Like

This is still a Worker :wink:
The same rules apply

That would be my guess

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.