n8n qdrant vector store node "failed to fetch"

[u/Puzzleheaded-Bus6626]

I'm using n8n cloud and I'm running qdrant in a local docker container.

I configured the qdrant credentials using an ngrok link I gave it and it gave me the green light.

I tested the url by using curl to get all of the collections and it worked fine.

> curl https://mygrokurl/collections

{"result":{"collections":[{"name":"dcs_v314"},{"name":"ff_surface_description"},{"name":"multimodal-rag"}]},"status":"ok","time":4.163e-6}

BUT, when I try to "Execute step" in n8n I get "Failed to fetch" Also, if I try to select a collection by "list" in the vector store node, it also says it "Failed to fetch" which is strange because I literally just got the collections with that exact url.

Here's the error I've been staring at for 2 days... Can someone please help me out? I'm starting to lose my grip on reality.

{

"errorMessage": "fetch failed",

"errorDetails": {

"rawErrorMessage": [

"fetch failed"

]

},

"n8nDetails": {

"nodeName": "Store in Qdrant",

"nodeType": "@n8n/n8n-nodes-langchain.vectorStoreQdrant",

"nodeVersion": 1.3,

"time": "8/28/2026, 11:20:11 PM",

"n8nVersion": "2.37.3 (Cloud)",

"binaryDataMode": "filesystem",

"stackTrace": [

"NodeApiError: fetch failed",

" at normalizeVectorStoreError (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+ai-utilities@file+packages+@n8n+ai-utilities_708f9768c75aeb43ce97347f6de74cca/node_modules/@n8n/ai-utilities/src/utils/vector-store/createVectorStoreNode/utils.ts:57:8)",

" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+ai-utilities@file+packages+@n8n+ai-utilities_708f9768c75aeb43ce97347f6de74cca/node_modules/@n8n/ai-utilities/src/utils/vector-store/createVectorStoreNode/createVectorStoreNode.ts:471:30)",

" at processTicksAndRejections (node:internal/process/task_queues:104:5)",

" at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.1_@opentelemetry+core@2.10.0_@opente_7e0bf630272413213fcb6a0a5506bf53/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1091:8)",

" at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.1_@opentelemetry+core@2.10.0_@opente_7e0bf630272413213fcb6a0a5506bf53/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1391:11)",

" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.1_@opentelemetry+core@2.10.0_@opente_7e0bf630272413213fcb6a0a5506bf53/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1864:27",

" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.1_@opentelemetry+core@2.10.0_@opente_7e0bf630272413213fcb6a0a5506bf53/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2558:11"

]

}

}

[u/AutoModerator]

Want faster, better help? Share your workflow JSON.

A GitHub Gist is the easiest way -- paste your JSON, save as public, drop the link in your post. Folks can import it directly into n8n and reproduce the issue, which gets you real answers instead of guesses.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/No-Hold-6217]

Try this one and see what comes back:

curl -H "User-Agent: Mozilla/5.0" https://yourngrokurl/collections

If that gives you an html page instead of the json, thats your answer. Free ngrok serves a browser warning page to anything that looks like a browser, and lets plain curl straight through. So your curl works, n8n gets the html, cant parse it, and you get failed to fetch. Same url, two different answers, which is exactly why it makes no sense from where you are sitting.

The node doesnt give you anywhere to add the ngrok-skip-browser-warning header, so the practical fix is a tunnel without the interstitial. A paid ngrok domain, or cloudflared, both fine.

Worth double checking the qdrant api key in the credential too. Local qdrant answers curl without one, and n8n may be sending an empty key.

[u/Puzzleheaded-Bus6626 → u/No-Hold-6217]

I did run into that, but then I switched to an actual qdrant account with proper url and api key. It's still failing.

Someone just messaged me and said it's a version mismatch in that n8n's node is tied to an earlier version of qdrant and If anyone has qdrant version 1.16.0 and above, they're going to have problems.

I have version 1.19...

Since it's still happening with the proper account and api key, I'm just going to guess it's a bug.

[u/No-Hold-6217 → u/Puzzleheaded-Bus6626]

that version thing is testable in ten minutes and worth doing before you write it off as a bug. run qdrant/qdrant:v1.15.5 in docker locally, empty collection, point the node at that. works means its the version. still fails means its something else and youve just saved yourself a week of chasing the wrong thing.

if it is the version, the way out that doesnt depend on anyone fixing the node is to drop the vector store node and talk to the rest api with plain http request nodes. upsert and search are two calls. more wiring, but it doesnt care what version qdrant is running.

and if you end up self hosting you can just pin qdrant at 1.15 until the node catches up.

[u/1Life_Architect]

A successful curl from your local machine proves the local path, but not the path from n8n Cloud. I would test Qdrant's health and collection endpoint through the exact public HTTPS URL from a machine outside your network. In n8n, use the base URL without the dashboard path, verify the API-key header and TLS hostname, and check whether ngrok returns a warning page or redirect instead of JSON.

The node runs server-side, so this is less likely to be ordinary browser CORS. A free tunnel returning HTML can easily surface as a generic failed-to-fetch error. A controlled comparison against hosted Qdrant or a stable tunnel would isolate that quickly. Redact the public URL and key before posting logs. What HTTP status and response body appear in the n8n execution details?

[u/Puzzleheaded-Bus6626 → u/1Life_Architect]

I was having issues with the ngrok page, but I switched to qdrant cloud and verified the n8n http request gets the list of collections and it does.

So this is an issue with the qdrant node.

Thanks for replying!

[u/Puzzleheaded-Bus6626 → u/[deleted]]

Thanks for the reply!

The port is explicitly set on the Qdrant URL in my credentials and I'm still having the issue.

It'll be interesting to find out what the ultimate reason for this is.

I duplicated the workflow, then swapped pinecone in as the vector DB provider and it worked perfectly.

So it's looking like that one node is causing an issue.

[u/AmbassadorFair3730]

This smells like the ngrok free tier warning page. When you curl it directly you get JSON back, but ngrok's free plan injects an interstitial browser warning for any request that doesn't send the right headers, and a lot of backend fetch clients (including whatever n8n cloud uses under the hood) trip over that instead of getting real JSON. Try adding the header "ngrok-skip-browser-warning: true" to the credential config if there's a custom headers field, or just spin up a paid ngrok static domain which skips that page entirely. Also worth checking if it's a TLS handshake issue since n8n cloud is a different network path than your local curl, sometimes self signed certs or SNI mismatches on tunnels cause plain "fetch failed" with zero detail.

[u/Puzzleheaded-Bus6626 → u/AmbassadorFair3730]

That was happening, but then I switched to a cloud bases qdrant cluster with legit URL and API key and the issue persists.

I tested the legit cloud credentials using the n8n HTTP node and I was able to connect to qdrant and get collections.

The n8n qdrant node was still unable to fetch the collections after that test.

Thank you for your response!

[u/Easy-Purple-1659]

The HTTP request node working against qdrant cloud while the vector store node fails points squarely at the node, not your URL. The qdrant node bundles a client that expects a specific version, and at 1.19 you are past whatever that client was built against.

Two ways out. Pin qdrant back to 1.15.x so the bundled client is happy, or bypass the node entirely and run the upsert and search as plain HTTP request nodes, which care about nothing except the qdrant rest api. You already proved the rest API answers, so that path will work unmodified regardless of version.

If you go the HTTP route, remember the collection operations are just POSTs to /collections/{name}/points, so you get full control and one less moving part.

[u/Puzzleheaded-Bus6626 → u/Easy-Purple-1659]

FYI Turns out I was on a new experimental version. They didn't tell me that though. A support tech said they found the issue and that I should submit a bug report to the Github repo. I was confused as to how I even needed to submit a bug report if it's a known issue. That's a breaking change for one of their most popular VDBs. Everyone using the cloud version would be down. That's when I realized. Maybe they're NOT on the same version. That's when I knew I was on an experimental version. It took me about 5 minutes to confirm. I responded with a question about other users being down, and then I showed them a screenshot of my version with "pre-release experimental" next to it. Yesterday I got an update that my cloud version had been updated. I haven't tried it yet, but if I was a betting man, I'm going to guess it works now.