cloudflared: immediate i/o timeout after connectTimeout change

After changing originRequest.connectTimeout, an application becomes unreachable. The log reports i/o timeout, sometimes during name resolution, even though almost no time has elapsed. An original remotely managed tunnel report describes this dependency. A suspected units problem is a hypothesis in that report, not a universally established cause. Q1

Keep different timeouts separate

Cloudflare distinguishes the TCP connection-establishment timeout from the TLS handshake timeout. Q2 Increasing one does not automatically extend the other. Dashboard inputs, API payloads, Terraform providers and local YAML can also have different representation requirements. The relevant contract is the interface you actually used.

Compare configuration with observed time

1. Preserve the precise change. Record the previous and new value, identifying whether it came from a dashboard, API response or provider. Remove tokens. A screenshot of an input box is not a substitute for the saved configuration.
2. Verify the active configuration. Check that the failing route uses the changed remote settings and that the connector received them. Compare global values and route-specific overrides separately rather than assuming one displayed setting controls every route.
3. Measure a harmless request. Record its start time and elapsed duration. Distinguish an immediate failure, failure near the intended timeout and a later application error. The word timeout alone does not capture these differences.
4. Check units for the actual interface. Consult the specific API or provider version's documentation. Do not copy a numeric value from an issue comment without checking its context. Seconds, duration strings and internal representations are not automatically interchangeable.
5. Remove one variable in a controlled comparison. Where operationally appropriate, compare a test instance using the previously working setting or omitting only this override. Keep DNS, origin and TLS settings unchanged. Success in that comparison narrows the configuration path involved.

Correct the source of the setting

If representation is wrong, repair the configuration generator and its subsequent automated application. If the saved value is correct but runtime timing differs, prepare a minimal reproducible comparison for the maintainer. A permanently enormous timeout can obscure the question and slow down other failure handling.

For support, include connector and provider versions, a sanitised configuration excerpt, measured durations and the identical request under the working comparison. After correction, verify that later infrastructure or configuration runs continue to produce the intended value. A manual dashboard edit can otherwise be silently overwritten by automation.

Frequently asked questions

Does lookup i/o timeout always mean the DNS server is faulty?

No. An already exhausted operation budget can also become visible at that stage. Check the timing and configuration relationship.

Should I simply enter nanoseconds?

No. Use only the representation required by the interface and version you actually operate.

Describe your case