Failure to trigger n8n workflow from jira, n8n is hosted inside a VM inside corporate firewall

[Basil Ali Khan]

We have an n8n container running inside a vm (on-prem) inside a corporate firewall.
We want to trigger the workflow whenever a jira comment is created. We are unable to do so. Nginx access and error logs do not show anything when we try to trigger the workflow.

We have allowed the inbound IP ranges of Jira on the firewall and all the traffic that falls onto public IP of the firewall, we map that to the private IP of the VM.

This is the current nginx config

Can someone help with what the issue could be?
We can see the webhook trigger request falling onto the firewall, it gets lost somewhere after that

[root@localhost ~]# nano /etc/nginx/conf.d/n8n.conf
  GNU nano 5.6.1              /etc/nginx/conf.d/n8n.conf
server {
listen 443 ssl;
server_name <server_name>; #removed for this msg

ssl_certificate /etc/nginx/ssl/n8n.cert;
ssl_certificate_key /etc/nginx/ssl/n8n.key;

# Recommended SSL settings
#ssl_protocols TLSv1.2 TLSv1.3;
#ssl_ciphers HIGH:!aNULL:!MD5;
#ssl_session_cache shared:SSL:10m;
#ssl_session_timeout 10m;

# Required for large headers (OAuth, JWT tokens)
#large_client_header_buffers 8 32k;
#client_max_body_size 100M;
proxy_buffering off;
proxy_buffers 16 16k;
proxy_buffer_size 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
large_client_header_buffers 4 32k;

location / {
proxy_pass http://localhost:5678;

# WebSocket support (critical for /rest/push)
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

# Forward 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;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port 443;

# Disable buffering (required for WebSocket/SSE)
proxy_buffering off;
proxy_cache off;
chunked_transfer_encoding on;

# Prevent timeout disconnections
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_connect_timeout 60s;
}

location /webhook/ {
proxy_pass http://127.0.0.1:5678;
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;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}

location /webhook-test/ {
proxy_pass http://127.0.0.1:5678;
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;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
}

# Redirect HTTP to HTTPS
server {
listen 80;
server_name <server_name>; #removed for this msg
return 301 https://$host$request_uri;
}

[Gabriela]

Hi @Basil Ali Khan, welcome to the Community. Nothing in your nginx logs means Jira Cloud isn't reaching your public endpoint at all, so the break is between Jira and your server, before nginx sees anything. Two common causes. The n8n Jira Trigger registers the webhook in Jira using whatever base URL your container advertises, and Jira Cloud only accepts an HTTPS callback. If WEBHOOK_URL (plus the X-Forwarded-Proto and Host headers nginx passes through) isn't set to your public https URL, n8n registers a bad callback or the registration gets rejected, so Jira has nowhere to send. The other is the firewall. Jira's outbound webhooks leave from Atlassian's egress proxies, and those ranges sit under Outgoing connections at https://ip-ranges.atlassian.com/, so allowlisting the inbound ranges drops them silently. Quickest way to bisect is to point the trigger at a throwaway https://webhook.site URL. If the event lands there, egress and registration are fine and it's your firewall or nginx path.