n8n cannot save workflows, and there is an issue with the HTTP node

Built with n8n
1

Bug Description

n8n cannot save workflows, which is particularly easy to trigger when SQL nodes and Code nodes are involved. The issue with the HTTP node is that when I call the API of a locally deployed LLM, it always times out and only succeeds occasionally, whereas running curl on the same machine works perfectly fine.

To Reproduce

  1. Run the workflow. 2. Modify any part of the workflow at random, including dragging nodes.

Expected behavior

1.http node timeout 2.It keeps prompting that it cannot connect to n8n, and if it lasts too long, it may even cause the container to crash.

Debug Info

Debug info

core

  • n8nVersion: 2.19.4
  • platform: docker (self-hosted)
  • nodeJsVersion: 24.14.1
  • nodeEnv: production
  • database: postgres
  • executionMode: regular
  • concurrency: -1
  • license: community
  • consumerId: unknown

storage

  • success: all
  • error: all
  • progress: false
  • manual: true
  • binaryMode: filesystem

pruning

  • enabled: true
  • maxAge: 336 hours
  • maxCount: 10000 executions

client

  • userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/139.0.0.0 safari/537.36
  • isTouchDevice: false

security

  • secureCookie: false

Generated at: 2026-06-22T03:30:05.033Z

Operating System

ubuntu 24.04

n8n Version

2.19.4

Node.js Version

24.14.1

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted

2

These are two separate issues to note here.

The HTTP node timeouts calling your local LLM and the fact that curl works fine but n8n times out. This points to a network namespace issue inside Docker. n8n’s container can’t reach localhost the same way your host machine can. You can try replacing localhost or 127.0.0.1 in your HTTP node URL with host.docker.internal instead. If that doesn’t help with your issue try bumping up the timeout value in your HTTP node to use as a stopgap while you debug further.

Regarding your workflow save failures, this is a known pain point on self-hosted setups under load, especially with Code and SQL nodes that are heavier on the backend. Chreck to make sure that your Postgres connection pool isn’t getting exhausted, check to make sure your container memory limits are not being hit during saves. Also review your n8n logs for any websocket disconnection errors which would explain why you are getting the “cannot connect to n8n” prompts. Running ‘docker stats’ during a failed save can quickly tell you if it’s a resource ceiling issue.

3

Guter Hinweis von @AnthonyAtXRay zum host.docker.internal. Das ist ein sehr häufiger Stolperstein bei Docker-Setups, ich bin selbst darüber gestolpert als ich lokale Services aus n8n heraus ansprechen wollte. Der Tipp mit docker stats während eines fehlgeschlagenen Saves ist ebenfalls sehr praktisch um schnell einzugrenzen ob es ein Ressourcenproblem ist.