Can axios enforce separate connection and read timeouts without external wrappers in v1.x?

Context

axios 1.x exposes a single timeout option that covers the entire request lifecycle—connection, response headers, and body download—with no built-in distinction between connection timeout and read timeout. The default value is 0 (infinite), which allows requests to hang indefinitely.

Constraint

In Node.js environments, the underlying http/https agents have independent timeout defaults (e.g., keep-alive sockets at two minutes). These agent-level timeouts can close sockets before axios's own timeout fires, surfacing as ECONNRESET rather than the expected ECONNABORTED error. axios does not expose per-request agent timeout configuration, and global agent settings affect all instances sharing the default agent.

Goal

Determine whether a production-grade axios setup can reliably enforce distinct connection and read deadlines using only axios's public API, or whether external wrappers or AbortController-based patterns remain the only viable path.

Specific questions:

1. Is there any documented or undocumented axios 1.x mechanism to set connectTimeout and readTimeout independently?
2. When Node.js agent timeouts interact with axios's single timeout, which error code (ECONNABORTED vs ECONNRESET) takes precedence under typical load?
3. Does AbortController cancellation in v1.7+ guarantee socket cleanup across all supported Node.js versions, or are leaks still possible for large response bodies?