`wrangler dev --remote` silently inherits rate limits from first custom domain route

[stephent]

Bug Report

What version of Wrangler are you using?

4.23.0

What operating system are you using?

macOS

Describe the Bug

When using wrangler dev --remote with custom domain routes configured, Wrangler silently applies the rate limiting policies from the first custom domain in the routes array to the development environment. This causes unexpected 429 errors during development and testing without any specific indication that domain-level rate limits were applied.

I believe this is unrelated to Cloudflare Workers Rate Limits, which I'm not using at present.

I can't see this behavior documented anywhere on https://developers.cloudflare.com/workers/platform/limits/.

Steps to Reproduce

1. Configure custom domain routes in wrangler.jsonc:

   {
     "routes": [
       {
         "custom_domain": true,
         "pattern": "api.example.com"
       },
       {
         "custom_domain": true,
         "pattern": "premium.api.example.com"
       }
     ]
   }

2. Set up rate limiting rules for api.example.com in Cloudflare dashboard ([Domain] → Security → Security rules → Rate limiting rules)

3. Run wrangler dev --remote

4. Make rapid requests to the dev server (e.g., running a test suite)

5. Observe 429 Too Many Requests errors after hitting the rate limit threshold

Expected Behavior

One of the following should happen:

1. Development environments should not inherit production rate limiting policies by default (preferred)
2. Clear warning/logging should indicate which domain's rate limits are being applied (alternatively)
3. Documentation should clearly explain this behavior and provide workarounds

Actual Behavior

• Rate limits from the first custom domain are silently applied to wrangler dev --remote
• No indication in logs or error messages that this is domain-related
• Developers receive generic 429 errors with no context about the underlying cause
• The behavior only affects --remote mode, not local development (I believe)

Example log lines:

[wrangler:info] GET /oauth/authorize 429 Too Many Requests (63ms)
[wrangler:info] GET /auth/access-token 429 Too Many Requests (69ms)

Additional Context

Permission/Workflow Issues:

• Developers with Workers permissions may not have access to view rate limiting rules in the Cloudflare dashboard
• Security teams managing rate limits may be unaware their changes affect Worker development environments
• This creates a disconnect where developers can configure routes in wrangler.jsonc etc. but cannot see the policies those routes inherit

Debugging Difficulty:

• Error appears as infrastructure issue rather than configuration issue
• No obvious connection between route configuration and rate limiting behavior
• Timing of errors might coincide with unrelated Cloudflare changes, making root cause analysis tricky

Workarounds Currently Required:

{
  "env": {
    "production": {
      "routes": [
        {
          "custom_domain": true,
          "pattern": "api.example.com"
        }
      ]
    },
    "development": {
      // No routes to avoid inheriting rate limits
    }
  }
}

Proposed Solutions

1. Add a flag such as --ignore-custom-domain-rules for development
2. Log warnings when domain rate limits are being applied in dev mode
3. Environment isolation: Don't apply production domain policies to development by default
4. Better error messages that indicate when 429s are due to inherited domain policies
5. Documentation explaining this behavior and recommended patterns

Impact

This issue can impact development workflows, especially for teams with:

• Automated testing that makes many rapid requests
• Separation of concerns between Workers developers and security/infrastructure teams
• Complex rate limiting policies on production domains

The silent nature of this behavior makes it problematic for debugging and can (has!) lead to wasted development time.