Error 1041 concerns an invalid value produced by a request header rewrite. Find the matching rule and evaluate the result for the failing request, rather than judging only its expression.
Review length and allowed characters against the applicable Cloudflare requirements. Shortening or changing a value must preserve the meaning expected by the receiving application.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Check the header value produced by the rule
| Evidence | Inspect | Next check |
|---|---|---|
| Static value fails | Exact configured text | Allowed characters and length |
| Only certain URLs fail | Dynamic expression result | Input-dependent expansion |
| Several rules match | Order and final intended value | Which operation produces the failure |
| Used for a label | Minimum useful information | Controlled value instead of a full description |
| Used for access or routing | Receiving application expectation | Meaning after any shortening |
Locate the rule that changes the header
Keep the affected address and the approximate failure time. In Cloudflare, review the request header rules that match that address, especially anything recently added or edited. Record the rule’s condition, header name, and value expression before adjusting it. A screenshot of the rule can make a later comparison much easier.
Suppose a rule adds a customer-facing label to requests under an API path. Most requests may produce a small value, while a particular URL supplies a much longer piece of text. The rule can look reasonable when you read its expression and still fail for that specific input. Testing only the homepage would miss the useful example.
If several rules match the same path, review their order and the final intended value. The rule you changed yesterday is a sensible starting point, but it should be connected to the failed request rather than blamed simply because it is new.
Look at the value, not just the expression
- Identify the matching rule and header name.
- Keep the failing request as test input.
- Determine the resulting value, not only the formula.
- Compare its format with official requirements.
- Review a controlled correction with the receiving application’s owner.
A static value is easier to inspect because you can read exactly what will be added. With a dynamic expression, work through the failing request and identify the resulting text. Long query strings, copied multi-line text, and concatenated values are worth examining when they are part of the expression.
For example, a short source label may be all the application needs. Copying an entire incoming address into that same field introduces far more data. If a label was the original purpose, producing a small, controlled value is usually easier to maintain than treating a header as a place to store an unrestricted request description.
Cloudflare’s header format documentation is the reference for which characters and lengths are supported. Avoid guessing a universal limit from a different server or a browser error. Different components can impose different constraints, and 1041 specifically concerns the rewrite performed here.
Make a small change that preserves the meaning
When the value is too long, shorten the value or the expression that generates it. When unsupported characters are involved, remove or replace those characters in a way that preserves the information the receiving application needs. A random truncation can make an error disappear while breaking the application’s interpretation of the field.
Consider a rule used to identify a request source. Replacing an oversized description with a stable source name may meet that purpose cleanly. By contrast, cutting an identifier in half could cause two different requests to appear identical. The person responsible for the receiving application should confirm that the revised value remains useful.
Save the original rule configuration so that the change is reversible. If the header participates in access decisions or routing, use a controlled test and review the receiving application’s expectations before changing its contents.
Confirm the original request works again
Test the original request, another request inside the rule and one outside it. If the value supports a submission or integration, verify that operation too. Removing the visible error can still leave the receiving system interpreting a truncated value incorrectly.
Retest the exact address that failed, then try another address that matches the rule and one outside its scope. This checks both the repaired value and the rule’s boundaries. A page outside the rule loading normally does not establish that the affected request is repaired.
If the site includes a form or API workflow on that path, complete a harmless test of the same workflow. A successful page response and a functioning submission are separate observations. Keep the test data simple so that it does not add another source of uncertainty.
Should 1041 continue, share the rule identifier, sanitized value expression, matching request path, and failure time with the administrator reviewing it. Avoid including passwords, session cookies, or private customer information in the example. The useful evidence is how the rule builds the header value and where that result stops meeting Cloudflare’s requirements.
Reference: Cloudflare error 1041 documentation.
Keep the field’s purpose with the rule
Record the rule identifier, sanitized expression, expected meaning and test inputs. That explains why the corrected value works and helps prevent the oversized or invalid expression from returning during a later migration.