N8n MCP Trigger, nginx, Gemini Enterprise

Questions
,
1

Has anyone had success with self hosted n8n behind nginx, to leverage Gemini Enterprise.

We have a basic workflow with a MCP trigger that we are trying to establish connectivity to for a test, with no authorization.

When Gemini Enterprise attempts to load custom actions, it 503 errors:

response_body: {“error”:{“code”:“UPSTREAM_CONNECTION_FAILURE”,“flag”:“UpstreamConnectionFailure”,“message”:“See go/conduit-troubleshooting#upstream-connection-failure for more information.”}}

We believe we have the /mpc location on nginx set up correctly (able to connect via postman), wondering if anyone else has had success.

2

Hey @dagarritysps, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Gallo_AIA, @Florian2, @zoubinho - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

One thing I wouldd check is the MCP transport.

Gemini Enterprise currently requires Streamable HTTP for custom MCP servers and does not support the legacy SSE transport.
So Postman reaching /mcp successfully doesn’t necessarily mean Gemini can complete the MCP handshake.

I would check the nginx logs while using Reload custom actions in Gemini.
That triggers a tools/list request and should show whether the request reaches nginx/n8n or fails before that.

If you can share the nginx log from one failed attempt that would probably narrow it down quickly.

4

When Gemini completes the reload data actions, nothing is hitting the nginx logs. Below are the Gemini logs, with the URL string redacted partially.

Failed HTTP calls to the MCP server for projects/970835352486/locations/global/collections/trakstar-hire_1790959419020/dataConnector:
POST http://n8n.sps-tech.com/mcp/XXXXXXX → HTTP 503
request_headers: {‘host’: ‘n8n.sps-tech.com’, ‘accept-encoding’: ‘gzip, deflate, br’, ‘connection’: ‘keep-alive’, ‘user-agent’: ‘python-httpx/0.27.0’, ‘authorization’: ‘’, ‘x-integration-connectors-dapper-trace-id’: ‘7245863224313262247’, ‘accept’: ‘application/json, text/event-stream’, ‘content-type’: ‘application/json’, ‘content-length’: ‘167’, ‘x-forwarded-proto’: ‘https’}
request_body: {“method”: “initialize”, “params”: {“protocolVersion”: “2025-11-25”, “capabilities”: {}, “clientInfo”: {“name”: “mcp”, “version”: “0.1.0”}}, “jsonrpc”: “2.0”, “id”: 0}
response_headers: {‘x-conduit-status-source’: ‘conduit’, ‘content-length’: ‘177’, ‘content-type’: ‘application/json’, ‘date’: ‘Fri, 02 Oct 2026 16:45:43 GMT’, ‘server’: ‘envoy’, ‘x-envoy-upstream-service-time’: ‘93’, ‘x-endpoint-load-metrics-bin’: ‘CaWBIzSHdn8/MTbmSnCMPGtA’, ‘x-google-cloud-conduit-region’: ‘us-central1’, ‘x-google-cloud-conduit-task-bns’: ‘/bns/jr/borg/jr/bns/cloud-conduit-vpc-proxy-prod-jobs/prod-us-central1.cloud-conduit-vpc-proxy/3’, ‘x-google-envoy-upstream-service-time’: ‘94’}
response_body: {“error”:{“code”:“UPSTREAM_CONNECTION_FAILURE”,“flag”:“UpstreamConnectionFailure”,“message”:“See go/conduit-troubleshooting#upstream-connection-failure for more information.”}}

5

We were able to get a local self hosted LLM through the reverse proxy, so I am thinking the issues is realted with the Gemini side configuration, which, does not seem to have a lot of options when no authorization is chosen except for the url.

6

That is actually a useful clue. If nothing reaches the nginx logs I would stop debugging nginx n8n for now and look at the Gemini Google Cloud side.

One thing worth checking is the egress policy. Google documents that with policy enforcement VPC Service Controls enabled the MCP server domain must be explicitly allowed in allowedEgressFqdns and custom_mcp must be an allowed data source.

Since Gemini is returning the 503 before nginx sees anything that would be my next place to look.

7

Gave those a shot, same 503. I feel I am missing something!

8

Hi @dagarritysps, your Gemini trace shows initialize going to http://.../mcp/..., with a Conduit 503 and no request in nginx. Google requires an HTTPS URL with a publicly trusted certificate for a custom MCP server.

Can you check the MCP Server URL saved in Gemini against the Production URL shown by n8n’s MCP Server Trigger? If Gemini has http:// saved, change it to the HTTPS URL and reload custom actions. The x-forwarded-proto: https header doesn’t confirm what URL is saved there.

If it already has HTTPS, test that same URL from outside your network while watching nginx’s access log. If the external test reaches nginx but Gemini still doesn’t, send Google support the failed request’s timestamp and trace ID.

9

Thank you for the help. Off to Google support I go!