CF-Connecting-IP is now a list of the same IP address

CF-Connecting-IP is now being sent as a list of IP address; in fact, the same IP address shows up twice, separated by a comma e.g. 1.1.1.1, 1.1.1.1.

As per the docs, this should not be the case:

CF-Connecting-IP has been a single IP address since I started using it last year, but since
Tue, Sep 28 2021, 8:48 PM (CEST) its been showing up as a list.

May I ask does this appear at your origin host / server logs or?

Furthermore, may I ask did you followed the instructions from below article or?:

May I ask does this appear at your origin host / server logs or?

Yes, this shows up in the origin/upstream logs.

Furthermore, may I ask did you followed the instructions from below article or?:

No, I use Argo tunnels for proxying to the upstream.

This is most certainly a bug in how CF-Connecting-IP is being set - would be nice to get a confirmation (or not) from a Cloudflare staff member. I’m not sure if it only happens within Argo tunnels or not. Also, I’ve since stopped relying on the header so I don’t know if this is still happening currently.

I can’t replicate this on my Argo Tunnel website.

Can you also try at your domain and see what IP address it returns?
https://example.com/cdn-cgi/trace

Thanks for responding @sdayman and sorry for my delayed response.

The trace output is:

fl=65f68
h=example.com [redacted]
ip=185.107.X.X [redacted]
ts=1634280798.939
visit_scheme=https
uag=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36
colo=CPH
http=http/3
loc=DK
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

I haven’t had a chance to deploy a service in an Argo Tunnel where I can log/verify the current value of the header. Maybe this’ll help:

  • cloudflared image: docker.io/cloudflare/cloudflared:2021.4.0
  • backend image: node:14.15.1-alpine; app running on fastify v3
  • proxied through: nginx:1.17.9-alpine

Nothing had changed in the deployment environment - no new deployments or restarts. The header’s value just abruptly changed. It might also be worth noting that the first error we saw had the header value as an IPv6 address, also duplicated, and then subsequent errors had IPv4 addresses, duplicated.