Introduction

This Node.js error means the HTTPS connection was dropped before the TLS handshake completed. The underlying cause is usually outside your application logic: the target host, port, proxy, certificate chain, TLS version compatibility, or a network middlebox closed the socket before Node could finish establishing a secure session.

Understand What Is Failing

When you call fetch("https://..."), Node must:

1. resolve the hostname
2. open a TCP socket
3. negotiate TLS
4. verify certificates
5. only then send the HTTP request

This error occurs before step 5 completes. That is why it is misleading to debug it as an ordinary HTTP application error. The request may never have reached the server as a valid HTTPS request at all.

A minimal failing example looks like this:

const response = await fetch("https://example.com/api");

If the TLS handshake fails first, fetch throws instead of returning a response object.

Check the Obvious Network and URL Problems First

The most common causes are simpler than people expect:

• using https:// against a server that only speaks plain HTTP
• connecting to the wrong port
• corporate proxy or firewall interruption
• DNS issues or unstable network paths
• the remote server closing idle or rejected connections early

A good first step is to reproduce the connection outside Node:

curl -v https://example.com/api
openssl s_client -connect example.com:443 -servername example.com

If these commands fail too, the issue is probably not specific to Node fetch. It is a network, DNS, TLS, or server-configuration problem.

If they succeed while Node fails, the next suspects are Node runtime version, proxy configuration, or client TLS options.

Verify TLS and Certificate Compatibility

Node uses its own TLS stack behavior and certificate verification rules. Handshake failures often come from:

• an incomplete certificate chain on the server
• self-signed or privately signed certificates
• unsupported protocol or cipher combinations
• SNI mismatch with the requested hostname

You can inspect the thrown error in detail:

1try {
2  const response = await fetch("https://example.com/api");
3  console.log(await response.text());
4} catch (err) {
5  console.error(err);
6  console.error(err.cause);
7}

That does not fix the problem, but it often reveals whether the failure is certificate-related, socket-related, or proxy-related.

If the server uses an internal CA, the proper fix is usually to trust the correct CA certificate rather than disabling verification globally.

Know When Proxies Are the Real Cause

In many company networks, direct outbound TLS is blocked or intercepted. In that environment, plain fetch may fail unless the process is configured to use the expected proxy path.

That explains why the same URL might work:

• in a browser
• in curl with proxy environment variables
• but not in a plain Node process

If your environment requires a proxy, configure that explicitly rather than assuming fetch will discover it automatically.

The same goes for containerized deployments. A container might not inherit the same trust store, DNS configuration, or outbound routing that your local shell has.

Confirm the Server and Port Match the Scheme

One of the easiest mistakes to miss is sending HTTPS to a port or service that is not actually speaking TLS.

For example, this looks plausible but can fail immediately:

await fetch("https://example.com:80/api");

Port 80 normally means plain HTTP, not HTTPS. Likewise, a reverse proxy may expose HTTPS on one port while the backend service expects plain HTTP on another.

Before changing client-side code, confirm:

• the scheme is correct
• the hostname is correct
• the port matches the scheme
• the server really presents TLS on that endpoint

Common Pitfalls

The biggest mistake is disabling TLS verification as the first response. That can hide certificate problems temporarily while introducing a much worse security problem.

Another issue is assuming the error means "fetch is broken." In most cases it means the network path or TLS negotiation broke before HTTP even started.

Developers also often debug only in Node and forget to verify the target with curl or openssl. External reproduction is one of the fastest ways to isolate whether the problem is environmental or application-specific.

Finally, do not overlook proxies and corporate certificates. Those are among the most common reasons the same code behaves differently between local machines, CI runners, and production servers.

Summary

• This error means the socket disconnected before TLS handshake completion.
• Start by validating the URL, port, and server outside Node with tools such as curl and openssl.
• Common causes include wrong scheme or port, certificate-chain issues, proxies, DNS problems, and server-side TLS misconfiguration.
• Inspect the thrown error details, but debug it as a connection setup problem rather than an HTTP response problem.
• Fix trust, proxy, or endpoint configuration explicitly instead of disabling TLS verification.