N8n 2.15.0 - AI Agent node with OpenAI Chat Model fails (service unable to process request) but HTTP Request node works fine

[Feng_Yuan_Zhang]

Hello everyone,

I’m experiencing a strange issue with n8n version 2.15.0 (running in Podman) when trying to use the OpenAI Chat Model node inside an AI Agent node. The credential test and workflow execution fail with generic error: “The service was not able to process your request”.

However, the exact same API endpoint works perfectly when I use a standard HTTP Request node with the same URL, headers, and body.

Environment

• n8n version: 2.15.0

• Deployment: Podman (on RHEL-9 server, IP 10.0.195.246)

• Podman run command:

  bash

  podman run -d --name n8n --network host --restart unless-stopped \
      --dns 10.0.3.6 \
      --dns 172.16.9.4 \
      -p 8080:8080 \
      -e NODE_TLS_REJECT_UNAUTHORIZED=0 \
      -e N8N_DIAGNOSTICS_ENABLED=false \
      -e N8N_LOG_LEVEL=debug \
      -v n8n_data:/home/node/.n8n \
      -v /opt/n8n/files/:tmp \
      -e N8N_LISTEN_ADDRESS=0.0.0.0 \
      -e N8N_PORT=8080 \
      -e N8N_PROTOCOL=http \
      -e N8N_HOST=10.0.195.246 \
      -e N8N_SECURE_COOKIE=false \
      n8nio/n8n:latest
  

• Target API: internal LLM gateway https://agent-api.CUSTOMERA.com.cn/ai-api/chat/completions (OpenAI-compatible, requires Bearer token)

What works

HTTP Request node works fine. Configuration:

• Method: POST

• URL: https://agent-api.CUSTOMERA.com.cn/ai-api/chat/completions

• Headers:

  • Authorization: Bearer jQ4J2LHXXXXXXXXvDE3sfMuE4

  • Content-Type: application/json

• Body (JSON):

  json

  {
    "model": "qwen-plus-latest",
    "messages": [{"role": "user", "content": "你是谁"}],
    "stream": true
  }
  

Result: successful response.

Curl from host machine works fine.

nslookup from inside n8n container resolves the domain correctly.

What fails

OpenAI Chat Model node inside an AI Agent node fails.

• Credential type: OpenAI Account

• Base URL set to: https://agent-api.CUSTOMERA.com.cn/ai-api (also tried with/without trailing slash)

• API Key: same as above

• Organization ID: left empty

• Model: qwen-plus-latest (also tried other names)

• Error message in UI: “The service was not able to process your request”

• No additional details in the node output.

n8n debug logs (from N8N_LOG_LEVEL=debug)

I enabled debug logging and captured the following errors (repeated occurrences):

text

2026-05-09T03:43:54.369Z [Rudder] error: Response error code: ETIMEDOUT
2026-05-09T03:43:54.369Z [Rudder] Error: Response error code: ETIMEDOUT

Error fetching feature flags Error [PostHogFetchNetworkError]: Network error while fetching PostHog
    at new PostHogFetchNetworkError (/usr/local/lib/node_modules/@nano/node_modules/.pnpm/posthog-node@3.2.1/node_modules/posthog-core/src/index.ts:41:5)
    at PostHog.<anonymous> (/usr/local/lib/node_modules/@nano/node_modules/.pnpm/posthog-node@3.2.1/node_modules/posthog-core/src/index.ts:546:17)
    at step (/usr/local/lib/node_modules/@nano/node_modules/.pnpm/posthog-node@3.2.1/node_modules/node_modules/tlslib/tlslib.es6.js:102:23)
    at Object.throw (/usr/local/lib/node_modules/@nano/node_modules/.pnpm/posthog-node@3.2.1/node_modules/node_modules/tlslib/tlslib.es6.js:83:53)
    at rejected (/usr/local/lib/node_modules/@nano/node_modules/.pnpm/posthog-node@3.2.1/node_modules/node_modules/tlslib/tlslib.es6.js:74:65) {
  error: DOMException [TimeoutError]: The operation was aborted due to timeout
    at node:internal/deps/undici/undici:16416:13,
  [cause]: DOMException [TimeoutError]: The operation was aborted due to timeout
    at node:internal/deps/undici/undici:16416:13
}

Also:

text

2026-05-09T05:04:48.129Z [Rudder] error: Response error occurred: ETIMEDOUT
...
2026-05-09T05:05:36.337Z [Rudder] error: Response error occurred: ENOENT

And later:

text

2026-05-09T05:04:23.887Z | debug | Querying database for waiting executions ...
Error fetching feature flags Error [PostHogFetchNetworkError]: Network error while fetching PostHog
...
  code: 'ERR_HTTP_HEADERS_SENT',
  extended: { 'x_nano': 'true' }

What I’ve tried (without success)

1. Changed Base URL to various forms: https://agent-api.``CUSTOMERA``.com.cn/ai-api, https://agent-api.sany.com.cn/ai-api/, https://agent-api.CUSTOMERA.com.cn/ai-api/v1

2. Added NODE_TLS_REJECT_UNAUTHORIZED=0 to bypass SSL verification

3. Switched to --network host in Podman (container uses host network)

4. Explicitly set DNS via --dns (host DNS servers: 10.0.3.6, 172.16.9.4)

5. Added NODE_OPTIONS="--dns-result-order=ipv4first"

6. Disabled firewalld on host (temporarily) – no change

7. Tested with minimal Alpine container – curl works fine, so container network is generally okay

8. Checked Podman version and tried recreating container multiple times

Suspected cause

• The OpenAI Chat Model node seems to make additional internal requests (e.g., /models endpoint) or handles the request differently than the raw HTTP node.

• The TIMEDOUT errors suggest that while DNS works, the TCP connection to the external API (or n8n’s telemetry services like PostHog) is timing out. However, the fact that HTTP Request node works contradicts a pure network issue.

• Possibly a bug in n8n 2.15.0 related to how the OpenAI credential constructs the request (headers, or use of Axios vs native fetch).

Request for help

Has anyone experienced similar issues with n8n 2.15.0 and OpenAI-compatible custom endpoints?
Is there a known workaround (other than using HTTP Request node)?
Could this be related to the way n8n handles streaming (stream: true) or the Authorization header format?

I’m willing to provide more logs or test patches. Thank you in advance.

[Feng_Yuan_Zhang]

Tried, efectless

[Feng_Yuan_Zhang]

[root@vla010000195246 ~]# curl -X GET "https://agent-api.sany.com.cn/api-apis/models" -H "Authorization: Bearer JQ4J2xxxxxxxDE3sFfMuE4" -H "Content-Type: application/json"
Internal server error

[Feng_Yuan_Zhang]

I have read the code , found this is intresting.

[Feng_Yuan_Zhang]

Upgrading to 2.20.6 did not resolve the issue – the behavior is exactly the same.

[Feng_Yuan_Zhang]

Thank you for your suggestion. I understand that calling the /chat/completions endpoint directly via HTTP Request node works perfectly.

However, I have to use the AI Agent node in my workflow because I need its native MCP support. The HTTP Request node alone cannot fulfill the requirements for MCP integration.

So I still need to resolve the issue with the OpenAI Chat Model node inside the AI Agent. Any further ideas would be greatly appreciated.

[Mirigu_2002]

@Feng_Yuan_Zhang Welcome to the community!

This looks more like an OpenAI-node compatibility issue than a network problem.

Since curl + HTTP Request work, your gateway is reachable.

Most likely:

• the OpenAI Chat Model node is calling /models

• or expecting stricter OpenAI-compatible responses/streaming behavior

Try:

• upgrading n8n (2.15.0 is old for AI nodes)

• stream: false

• adding /v1 to Base URL

• testing the OpenAI node outside the AI Agent

Honestly, if HTTP Request already works, that’s probably the safest workaround for now

[Feng_Yuan_Zhang]

@Mirigu_2002 Thanks a lot for your suggestions and for the warm welcome!

Here’s what I’ve tried based on your advice:

1. Upgrade n8n – I upgraded to 2.20.6, but unfortunately the issue persists.

2. Streaming – I tested both stream: false and stream: true in the node configuration. Neither worked.

3. Add /v1 to Base URL – I also tried adding /v1 to the Base URL, but it didn’t help.

Additional test with an Nginx proxy:

I set up an Nginx proxy to forward requests starting with /ai-api/ to the real gateway. Then I configured the OpenAI Chat Model node with:

• Base URL: http://your-proxy-domain.com/ai-api

With this setup, the Credential test passed (which is an improvement), but when running the workflow, the node fails with a new error:
other side closed (as shown in the attached log).

Root cause confirmed:

Based on my tests, the /models endpoint is missing or incorrectly implemented on our internal LLM gateway. When the OpenAI Chat Model node tries to call /models, the gateway returns an error (or closes the connection), which leads to the failure. The HTTP Request node works because it only calls /chat/completions and does not depend on /models.

Current plan:

I have asked our AI R&D team to make the gateway fully compliant with the standard OpenAI API protocol, including proper support for the /models endpoint. I hope they will fix it soon.

In the meantime, I agree with you – using the HTTP Request node is the safest workaround. But I still need the AI Agent node for MCP support, so I’ll keep pushing for the gateway fix.

Thanks again for your help!