Front-end Execution not working (DNS or SSL problem?)

I Deployed n8n on docker with Nginx.
The deployment seems fine.
But when I access n8n through the domain the executions are stuck in the front-end.
When testing with a different Domain It does work fine. (without changing any env variables to the new domain, as I have only set the webhook URL)

WEBHOOK_URL=https://n8n.errordomain.com/
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NODE_VERSION=16.14.2
YARN_VERSION=1.22.18
NODE_ICU_DATA=/usr/local/lib/node_modules/full-icu
N8N_SMTP_HOST=smtp.sendgrid.net
N8N_SMTP_USER=apikey
N8N_SMTP_PASS=*&^*@#^
N8N_EMAIL_MODE=smtp
N8N_SMTP_SENDER=*&^*@#
N8N_SMTP_PORT=587
N8N_SMTP_SSL=false

n8n.errordomain .com
Wix .com website and DNS pointing to the n8n server which is on a Hetzner cloud hosting server.
SSL from Lets Encrypt through the setup in nginx.

  • webhooks work fine through this domain.
  • executions stay “running” not doing anything. It should be creating a ticket in Monday, which it does not. so it is actually stuck on something not just showing that it is stuck.

n8n.workingdomain .com
Cloudflare DNS
Cloudflare SSL

  • No problem found at all.

Because only the DNS and SSL are different I think one of these might be the problem.
Hope someone knows what is going wrong.

Information on your n8n setup

  • n8n version: 0.171.1
  • Database you’re using (default: SQLite): Default
  • Running n8n with the execution process [own(default), main]: Default
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker

Hey @BramKn, sorry to hear you are having trouble here. It almost sounds like the server events don’t reach your browser.

Seeing you are using nginx, do both of your domains use the same reverse proxy config? Here is a recent example:

I am typically using this nginx location directive unless something breaks, but it seems to be fine with n8n:

image

1 Like

Hi @MutedJam

They are identical in nginx except for the SSL and domain of course.

The webhooks are working though, that is something that does not make sense to me.
They are both still enabled and working. I can access anything, just not run anything in the front-end for one of em.

I am working with the GUI


image
image

Yes, this very much sounds like your server can’t send data to the browser at the moment. Might not necessarily be the reverse proxy but could also be a particularly strict firewall.

As for your GUI I am not familiar with Nginx Proxy Manager. Are you using the same configuration in there for both of your domains? How does the effective nginx server block created by this tool look like?

The good news is I use Nginx Proxy Manager with the same settings for my instances and it is working ok. I have not tried using 2 different domains though, Which domain works? As a test it might be worth setting the vue app environment variable to see if that helps but it will only work properly for one domain.

Out of interest what other keys do you have set for n8n? Do you have N8N_HOST set?

Hi @MutedJam & @Jon

Thank you both for the quick response.

The firewall of the server is of course the same with both routes. Is it possible Wix.com has some kind of firewall as well? I am not that familiar with these kinds of things.

Is this what you meant by server block?

{
  "domain_names": [
    "WorkingDomain.nl"
  ],
  "forward_scheme": "http",
  "forward_host": "n8n",
  "forward_port": 5678,
  "block_exploits": true,
  "allow_websocket_upgrade": true,
  "access_list_id": 0,
  "certificate_id": 8,
  "ssl_forced": true,
  "meta": {
    "letsencrypt_agree": false,
    "dns_challenge": false
  },
  "advanced_config": "",
  "locations": [],
  "caching_enabled": false,
  "http2_support": false,
  "hsts_enabled": false,
  "hsts_subdomains": false,
  "owner_user_id": 1
}
{
  "id": 1,
  "created_on": "2022-04-05T13:28:57.000Z",
  "modified_on": "2022-04-07T07:03:56.000Z",
  "owner_user_id": 1,
  "domain_names": [
    "ErrorDomain.com"
  ],
  "forward_host": "n8n",
  "forward_port": 5678,
  "access_list_id": 0,
  "certificate_id": 7,
  "ssl_forced": true,
  "caching_enabled": false,
  "block_exploits": true,
  "advanced_config": "",
  "meta": {
    "letsencrypt_agree": false,
    "dns_challenge": false
  },
  "allow_websocket_upgrade": true,
  "http2_support": false,
  "forward_scheme": "http",
  "enabled": 1,
  "locations": [],
  "hsts_enabled": false,
  "hsts_subdomains": false
}

I have tried the N8N_HOST and other env variables when trying to fix it. It did not help. I reverted it to the most simple setup, the complete setup is shown in the original post. I only edited some Password values and such, did not remove any variables.
I could of course have the N8N_HOST set wrong when trying to fix it. But it’s strange how this would be the cause as the other Domain does work without it.

The .nl domain works, this is my own domain I tried.
The .com domain is from the client which does not work.

Before I added the .nl domain it was just the one .com domain and also did not work.

I am not familiar with the “vue app environment variable” It’s just that one env Variable to put in?
How could it be needed for one but not the other. :thinking:

It might be worth checking the browser network tab and that will show a bit more about what is being blocked if anything, I have just attempted to set up 1 instance using 2 differnet domains and it appeared to work but in my test it was 2 subdomains rather than 2 different domains.

I have to ask what are you you to with the 2 different domains for one instance?

Hi @Jon

I will take a look at the network tab when I get the chance. I already did, but did not see any difference then. Will try again to see if I can spot something now and get some screenshots.

The second domain is only configured because the first one has the issue. When it is resolved I will remove the second domain. I added this domain because I knew it was working fine with my own instance and wanted to rule out that the domain was the issue. Which I could not do because it is working fine with my domain. :sweat_smile:

Ah ok, I would assume the domain is ok but what I would do is set the 2 options below and see if that changes anything.

N8N_HOST=n8n.ErrorDomain.com
VUE_APP_URL_BASE_API=https://n8n.ErrorDomain.com

Thanks, I will try that later.

I have checked the network in my browser when going to both domains.
I see a difference with the remote address IP in the header.

The working Domain shows the IP of Cloudflare.
The Domain with the issue shows the Server IP.

No clue if this is something that could cause this behaviour.

Request URL: https://errorDomain.com/rest/workflows/run
Request Method: POST
Status Code: 200 OK
Remote Address: ServerIP:443
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, sessionid
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Origin: http://localhost:8080
Connection: keep-alive
Content-Length: 30
Content-Type: application/json; charset=utf-8
Date: Fri, 08 Apr 2022 11:29:11 GMT
ETag: W/"1e-15FhNEYTccZmjADPlgV3AkpgqD0"
Server: openresty
Vary: Accept-Encoding
X-Powered-By: Express
X-Served-By: errorDomain.com
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7,af;q=0.6
Connection: keep-alive
Content-Length: 437
Content-Type: application/json
Cookie: lhc_per={<replaced>}; n8n-auth=<replaced>
Host: errorDomain.com
Origin: https://errorDomain.com
Referer: https://errorDomain.com/workflow/3
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
sessionid: rre4jbysn8e
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Safari/537.36
Request URL: https://WorkingDomain.nl/rest/workflows/run
Request Method: POST
Status Code: 200 
Remote Address: CloudflareIP:443
Referrer Policy: strict-origin-when-cross-origin
access-control-allow-credentials: true
access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, sessionid
access-control-allow-methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
access-control-allow-origin: http://localhost:8080
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
cf-cache-status: DYNAMIC
cf-ray: 6f8aa95aad096b4a-AMS
content-length: 30
content-type: application/json; charset=utf-8
date: Fri, 08 Apr 2022 11:28:47 GMT
etag: W/"1e-DK0wTZi5wlOsEPKQSeA24u1oLys"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=<replaced>"}],"group":"cf-nel","max_age":604800}
server: cloudflare
vary: Accept-Encoding
x-powered-by: Express
x-served-by: WorkingDomain.nl
:authority: WorkingDomain.nl
:method: POST
:path: /rest/workflows/run
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7,af;q=0.6
content-length: 437
content-type: application/json
cookie: n8n-auth=<replaced>
origin: https://WorkingDomain.nl
referer: https://WorkingDomain.nl/workflow/3
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
sessionid: hj8aesnf41f
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Safari/537.36

hi @Jon

I put in both env vars. Sadly it did not change a thing.

Do you have any other ideas?

Hey @BramKn,

That is all I have, Are you able to share / DM a link and a user account so we can see if anything looks odd from the outside?

Thanks again Jon.

This issue was caused by Bitdefender(internet security) blocking the SSL certificate provided by lets encrypt.
Bitdefender only showed this notification after opening the GUI, was not giving me any Notifications while I was having the issue.

1 Like