Webhooks between Docker Containers

Hi,
I’m trying to make some workflow that is communicating between my Docker containers. My use case is to send a webhook from my Discourse instance to n8n and trigger some workflow.

In development I connected to the discourse container and tried to execute the curl which results in:

root@forum:/ curl http://n8n:5678/webhook-test/3/webhook/test
{"code":404,"message":"The requested webhook is not registred."}

root@forum:/ curl http://n8n:5678/webhook/3/webhook/test
{"code":404,"message":"The requested webhook is not registred."}

I clicked on Execute Workflow. From my browser, I’m able to enter the route and trigger the webhook.
The same goes for the production Webhook (in active state).
image

Here is my docker-compose.yml:

version: "3.7"

services:
  traefik:
    image: traefik
    container_name: traefik
    restart: always
    command:
      #- "--log.level=DEBUG"
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --providers.docker
      - --api
      - "--certificatesresolvers.mytlschallenge.acme.tlschallenge=true"
      #- "--certificatesresolvers.mytlschallenge.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"
      - "[email protected]"
      - "--certificatesresolvers.mytlschallenge.acme.storage=/letsencrypt/acme.json"
      - --metrics
      - --metrics.influxDB
      - "--metrics.influxDB.address=influxdb:8089"
    ports:
      - "80:80"
      - "443:443"
    networks:
      - web
      - internal
    volumes:
      - "/home/test/traefik/acme.json:/letsencrypt/acme.json"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  n8n:
    image: n8nio/n8n
    container_name: "n8n"
    restart: always
    networks:
      web:
      internal:
    volumes:
      - /home/test/n8n/.n8n:/root/.n8n
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${ID}
      - N8N_BASIC_AUTH_PASSWORD=${PW}
      - N8N_HOST=n8n.${DOMAIN_NAME}.de
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - N8N_PORT=5678
      - GENERIC_TIMEZONE=Europe/Berlin
      - WEBHOOK_TUNNEL_URL=https://n8n.${DOMAIN_NAME}.de/
      - VUE_APP_URL_BASE_API=https://n8n.${DOMAIN_NAME}.de/
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.${DOMAIN_NAME}.de`)"
      - "traefik.http.routers.n8n.entrypoints=websecure"
      - "traefik.http.routers.n8n.tls=true"
      - "traefik.http.routers.n8n.tls.certresolver=mytlschallenge"
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"
      - "traefik.http.middlewares.n8n.headers.SSLRedirect=true"
      - "traefik.http.middlewares.n8n.headers.STSSeconds=315360000"
      - "traefik.http.middlewares.n8n.headers.browserXSSFilter=true"
      - "traefik.http.middlewares.n8n.headers.contentTypeNosniff=true"
      - "traefik.http.middlewares.n8n.headers.forceSTSHeader=true"
      - "traefik.http.middlewares.n8n.headers.SSLHost=${DOMAIN_NAME}"
      - "traefik.http.middlewares.n8n.headers.STSIncludeSubdomains=true"
      - "traefik.http.middlewares.n8n.headers.STSPreload=true"

The Discourse Instance is managed in a different file but is reachable for n8n.

Thank you.

Hm does not really make any sense. If you get the message “The requested webhook is not registred.” it means that you did reach n8n. So the communication works.

That means that if you have the workflow active (for production-mode) or you are currently executing it in dev-mode it should start the workflow just fine.

Did you get it working?

Hey

I didn’t try it since then. But I get very inconsistent results when I want to trigger a webhook. Active Webhooks are not registered and do not work -others work. Production Webhooks are accessible via my computer, but on my server (where the container ist running) it states that the webhook is not registered. This confuses me a lot. :thinking:

That sounds very strange. Never had problems like that. The only times a registered Webhooks did not work for me is if I had POST-Webhooks and I called them via GET which can obviously not work. Also did never hear about similar problems from anybody else before. So either you are the first one to hit a very strange bug (which is possible) or it is somehow related to your setup.