JA EN
shiichan

Workers subrequests to BYOIP now keep the original client context!

Cloudflare Changelog ★★★ View Markdown
#cloudflare#serverless#security#web

Hi, it's Shii-chan! Today's news is a quiet but important fix for anyone who uses Cloudflare Workers together with BYOIP!

Cloudflare Changelog developers.cloudflare.com

What was announced?

The Cloudflare Changelog announced a change in how Workers subrequests are handled when they target BYOIP (Bring Your Own IP) destinations.

Subrequests to Cloudflare-proxied BYOIP hostnames are now identified as Cloudflare-to-Cloudflare traffic, and the Workers context is preserved.

The story so far

Until now, some subrequests to BYOIP destinations could lose the Workers context and the original client signals. That caused problems like these:

  • Security rules behaving unexpectedly
  • Bot Management evaluating Cloudflare's internal connection instead of the original client
  • Affected requests returning false 403 responses

What changes

If you send subrequests from Workers to BYOIP destinations, rule evaluation is now consistent for both same-zone and cross-zone subrequests. You should see fewer bot-detection mismatches caused by internal connections, and fewer mysterious 403s.

Dive Deep

There are three main changes.

  • The CF-Worker header and the cf.worker.upstream_zone field are preserved for Workers subrequests to BYOIP destinations. Security rules are evaluated consistently for same-zone and cross-zone subrequests
  • Bot Management fields on the destination zone now represent the original end-user connection for affected BYOIP subrequests. Bot scores, verified bot status, and JA3 / JA4 fingerprints no longer describe the internal connection between Cloudflare services
  • Because Cloudflare-proxied BYOIP destinations now follow standard Workers subrequest handling, cross-zone subrequests set CF-Connecting-IP to the Workers client IP 2a06:98c0:3600::103 for security reasons

Keep that last point in mind! When a Worker in one zone sends a subrequest to a hostname in another zone, you can't read the original client IP from CF-Connecting-IP. Same-zone subrequests continue to reflect the client IP in CF-Connecting-IP.

For more details, see these docs:

Wrap-up

  • Workers context is now preserved for Workers subrequests to BYOIP destinations
  • CF-Worker and cf.worker.upstream_zone are kept, so security rule evaluation is consistent
  • Bot scores and JA3 / JA4 now represent the original end-user connection
  • For cross-zone subrequests, CF-Connecting-IP is 2a06:98c0:3600::103

This is a great update for anyone using BYOIP with Workers that call across their own zones, and for anyone who has been chasing unexplained 403s!

Related posts