First Workflow Issue: Possible Environments Variable Issue while using MCP Client

[mallamace]

I’m attempting to build my first Workflow, I’m getting this error. Is this indicative of a configuration issue at the server-level, the n8n-level, or apify-level? I’m not sure where to begin,

Please share your workflow

I’m setting up connection to my MCP Client:
Command: npx
Arguments: -y @apify/actors-mcp-server --actors matej.vavro/Coingecko
Environments: APIFY_TOKEN=(My Token)

When I go back to edit enviroment setting I see “_n8n_BLANK_VALUE…” according to ChatGPT " *field was saved but blanked out by the UI (often happens with secrets for security)" – is this true?

I set an environment variable at “docker=compose.yml” and called it in my environment field:

APIFY_TOKEN={{ $env.APIFY_TOKEN }}

I still see the “_n8n_BLANK_VALUE…”

What is the error message (if any)?

I click “SAVE” and I get error bottom-right notification:
“Problem running workflow Lost connection to the server”

n8n setup information

• Deployment type: Self-hosted via Docker
• Server: 1 vCPU / 1 GB RAM VPS (with 2GB swap enabled)
• Running with: Docker Compose
• Community node: n8n-nodes-mcp
• n8n Version: 1.90.2

docker-compose.yml

services:
  n8n:
    image: n8nio/n8n
    ports:
      - "(PORT #):(PORT #)"
    volumes:
      - ./n8n_data:/home/node/.n8n
    environment:
      - APIFY_TOKEN=apify_api_(MY TOKEN)
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=(USER)
      - N8N_BASIC_AUTH_PASSWORD=(PASSWORD)
      - TZ=America/Los_Angeles
      - N8N_HOST=(MY HOST)
      - N8N_PROTOCOL=https
      - N8N_PORT=(PORT #)
    restart: always

Please let me if any additional information would be helpful.

[mallamace]

Steps we took to resolve the “Lost connection to the server” error encountered when executing an MCP Client node that runs an npx command within a Dockerized n8n setup behind an NGINX reverse proxy.

Issue Summary

• Deployment Details:

  • n8n Version: 1.90.2
  • Deployment Method: Docker Compose
  • Reverse Proxy: NGINX with Let’s Encrypt SSL
  • Domain: automation.(MY DOMAIN)
  • VPS Provider: DownDoggy.com (1 vCPU, 1 GB RAM)[n8n

• Problem Encountered:

  • Running an MCP Client node that executes npx -y @apify/actors-mcp-server --actors (MY ACTOR) resulted in the n8n UI displaying:

“Problem running workflow – Lost connection to the server”

• Despite the UI error, the backend process continued running.

---

Root Cause

The issue stemmed from the NGINX reverse proxy not being configured to handle WebSocket connections properly. n8n relies on WebSockets for real-time communication between the server and the browser UI. Without the appropriate NGINX configuration, the WebSocket connection was not established, leading to the UI losing connection during long-running workflows.

---

Solution

We updated the NGINX configuration to support WebSocket connections and increased timeout settings to accommodate long-running processes.

Updated NGINX Configuration:

nginx

CopyEdit

server {
    listen 443 ssl;
    server_name (MY DOMAIN);

    ssl_certificate /etc/letsencrypt/live/automation.(MY DOMAIN)/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/automation.(MY DOMAIN)/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://localhost:(PORT #);

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Standard headers
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts for long-running workflows
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

server {
    listen 80;
    server_name automation.(MY DOMAIN);

    if ($host = (MY DOMAIN)) {
        return 301 https://$host$request_uri;
    }

    return 404;
}

Steps Taken:

1. Edit NGINX Configuration:

• Updated the /etc/nginx/sites-available/n8n file with the above configuration.

2. Test and Reload NGINX:

• Ran sudo nginx -t to test the configuration.
• Executed sudo systemctl reload nginx to apply the changes.

---

Post-Implementation Results

• The n8n UI no longer displays the “Lost connection to the server” error during long-running workflows.
• The MCP Client node executes successfully, and the UI remains responsive throughout the process.

---

Acknowledgments

A special thanks to the community members who highlighted the importance of proper WebSocket configuration in reverse proxies:

• Connection lost repeated
• I updated n8n to 1.5 im getting connection lostn8n Communityn8n Community+2n8n Community+2n8n Community+2

Their insights were instrumental in identifying and resolving the issue.