# Workers subrequests to BYOIP now keep the original client context!

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

## 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:

- [Cloudflare BYOIP](https://developers.cloudflare.com/byoip/)
- [CF-Worker header](https://developers.cloudflare.com/fundamentals/reference/http-headers/#cf-worker)
- [cf.worker.upstream_zone](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.worker.upstream_zone/)
- [Bot Management variables (O2O and subrequests)](https://developers.cloudflare.com/bots/reference/bot-management-variables/#o2o-and-subrequests)
- [CF-Connecting-IP in Worker subrequests](https://developers.cloudflare.com/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests)
- [Workers subrequest limits](https://developers.cloudflare.com/workers/platform/limits/#subrequests)

## 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!