n8n HTTP Request Node Aborts with TLSSocket.socketCloseListener Error

Below is a list of suggestions that may help troubleshoot and resolve your issue with the HTTP Request node:

1. Connection/Timeout Issues

Even though the data size is far below the 16MB default, a large payload (such as 1000+ records) might take longer to process. The error you’re seeing:

  Error: aborted at TLSSocket.socketCloseListener ...

can mean that the underlying TLS connection is being closed before the full payload is received. Check if:

• The Mikrotik device is timing out or closing the connection when the response takes longer.
• There is a timeout setting (in your HTTP Request node under additional options) that may need to be increased. If available, try setting a longer timeout so that n8n doesn’t abort the connection prematurely.

2. TLS/SSL Settings

If your Mikrotik device is using self-signed or untrusted certificates, it could cause the connection to drop under heavier loads. Consider:

• Checking the TLS/SSL settings. In some cases, setting the node to “insecure” (i.e., bypass certificate validation) or adjusting TLS options can help troubleshoot whether it’s a certificate-related issue.

3. Batching the Request

Although your payload is only 360 kB in total when using cURL, you might be hitting a network or device-specific limitation when a large number of records is returned. One approach that has worked for many users (especially for integrations that return large responses) is to retrieve data in smaller batches. You can:

• Use the HTTP Request node’s batching options (if applicable to your use case) to break the request into smaller chunks.
• Alternatively, if the API allows it, adjust the parameters (for example, adding pagination) to receive a smaller number of records per call.

4. Retries and Error Handling

You can also use the node’s built-in options to retry on a failed request:

• In your HTTP Request node’s settings, enable Retry on Fail and configure retry parameters. This can help in cases where the failure is intermittent or related to network stability.

5. Compare cURL and HTTP Request

Since the same GET request with cURL works fine, double-check:

• That the HTTP Request node is using the same request method, headers, and authentication details (if applicable).
• That any differences in connection options (such as user-agent or TLS settings) aren’t causing the firewall to behave differently.

---

By checking for timeout issues, verifying TLS settings, possibly breaking up the request, and enabling retries, you can help narrow down whether the error is due to network limitations, how the Mikrotik device handles long or large responses, or a setting in the HTTP Request node itself.

If the issue persists, you might find more detailed diagnostic information by increasing logging on your n8n instance or checking the Mikrotik device logs.