Nginx Proxy Manager无法将请求转发到vaultwarden
Nginx Proxy Manager无法将请求转发到vaultwarden
You're trying to deploy Vaultwarden on a Raspberry Pi 4 with Nginx and Duck DNS configured. You've followed several setup guides and have Docker running, but you're encountering a 504 gateway timeout when using the Duck DNS domain. The port 80 and 443 are open via UFW, and your Nginx configuration appears correct. You've attached logs from Docker containers to help troubleshoot. Keep in mind that a 504 error typically means the backend service is unreachable, which could be due to network issues, incorrect DNS resolution, or misconfigured routing. Review the logs for details on errors and consider verifying DNS propagation and firewall rules.
HE-RSA-AES256-CCMHE-RSA-AES256-CCM8HE-RSA-AES256-GCM-SHA384HE-RSA-AES128-CCMHE-RSA-AES128-CCM8HE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256; # Perfect Forward Secrecy(PFS) is frequently compromised without this ssl_prefer_server_ciphers on; ssl_session_tickets off; # Enable SSL session caching for improved performance ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; # By default, the buffer size is 16k, which corresponds to minimal overhead when sending big responses. # To minimize Time To First Byte it may be beneficial to use smaller values ssl_buffer_size 8k; # Security headers ## X-Content-Type-Options: avoid MIME type sniffing add_header X-Content-Type-Options nosniff; ## Content-Security-Policy (CSP): Yes ## No 'script-src' directive, you need to test it yourself add_header Content-Security-Policy "object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; frame-ancestors 'self';"; ## The safest CSP, only block your website to be inside an inframe # add_header Content-Security-Policy "frame-ancestors 'self';"; ## Strict Transport Security (HSTS): Yes add_header Strict-Transport-Security "max-age=15552001; preload" always; client_max_body_size 128M; location / { proxy_http_version 1.1; proxy_set_header "Connection" ""; 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_pass http://vaultwarden-default; } location /notifications/hub/negotiate { proxy_http_version 1.1; proxy_set_header "Connection" ""; 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_pass http://vaultwarden-default; } location /notifications/hub { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Forwarded $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://vaultwarden-ws; } }
You're forwarding to port 8080, but it looks like Vaultwarden is configured to listen on port 80: [2023-10-11 17:36:54.862][start][INFO] Rocket has launched from http://0.0.0.0:80 This is what it looks like on my machine: [2023-10-08 09:27:54.300][vaultwarden::api::notifications][INFO] Starting WebSockets server on 0.0.0.0:3012 [2023-10-08 09:27:54.305][start][INFO] Rocket has launched from http://0.0.0.0:8080 Not sure how much it'll help you since you're using UI tools for configuration, but this is what my nginx-configuration for Vaultwarden looks like: Spoiler # The `upstream` directives ensure that you have a http/1.1 connection # This enables the keepalive option and better performance # # Define the server IP and ports here. upstream vaultwarden-default { zone vaultwarden-default 64k; server 127.0.0.1:8080; keepalive 2; } upstream vaultwarden-ws { zone vaultwarden-ws 64k; server 127.0.0.1:3012; keepalive 2; } # Redirect HTTP to HTTPS server { listen 80; listen [::]:80; server_name <external-hostname>; access_log /var/log/nginx/vaultwarden_access.log vaultwarden; error_log /var/log/nginx/vaultwarden_error.log; # Don't show the nginx version number, a security best practice server_tokens off; return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name <external-hostname>; access_log /var/log/nginx/vaultwarden_access.log vaultwarden; error_log /var/log/nginx/vaultwarden_error.log; # Don't show the nginx version number, a security best practice server_tokens off; ssl_dhparam /etc/nginx/dhparams.pem; ssl_certificate /etc/letsencrypt/live/<external-hostname>/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/<external-hostname>/privkey.pem; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/<external-hostname>/fullchain.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384HE-RSA-AES256-CCMHE-RSA-AES256-CCM8HE-RSA-AES256-GCM-SHA384HE-RSA-AES128-CCMHE-RSA-AES128-CCM8HE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256; # Perfect Forward Secrecy(PFS) is frequently compromised without this ssl_prefer_server_ciphers on; ssl_session_tickets off; # Enable SSL session caching for improved performance ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; # By default, the buffer size is 16k, which corresponds to minimal overhead when sending big responses. # To minimize Time To First Byte it may be beneficial to use smaller values ssl_buffer_size 8k; # Security headers ## X-Content-Type-Options: avoid MIME type sniffing add_header X-Content-Type-Options nosniff; ## Content-Security-Policy (CSP): Yes ## No 'script-src' directive, you need to test it yourself add_header Content-Security-Policy "object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; frame-ancestors 'self';"; ## The safest CSP, only block your website to be inside an inframe # add_header Content-Security-Policy "frame-ancestors 'self';"; ## Strict Transport Security (HSTS): Yes add_header Strict-Transport-Security "max-age=15552001; preload" always; client_max_body_size 128M; location / { proxy_http_version 1.1; proxy_set_header "Connection" ""; 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_pass http://vaultwarden-default; } location /notifications/hub/negotiate { proxy_http_version 1.1; proxy_set_header "Connection" ""; 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_pass http://vaultwarden-default; } location /notifications/hub { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Forwarded $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://vaultwarden-ws; } }
Basilecool
03-23-2022, 07:23 AM #3I discovered the mistake of not opening port 8080 in the firewall.
TheSymbiote
03-23-2022, 07:55 AM #4Avoid opening port 8080 in the firewall. This port must remain hidden from external access. Your server should only be accessible via ports 80 and 443, which should be managed by nginx. Nginx will then redirect traffic to port 8080 internally (127.0.0.1/localhost).
wintery_kid13
03-24-2022, 11:41 AM #6It seems you're observing a series of steps in a network process. Initially, the domain resolves to your external IP without any forwarding. When accessing the site, your browser sends a request that gets routed through your router, which then forwards it to the internal server on port 80. The server responds via HTTPS, and the browser reattempts using port 443. Your router decrypts the traffic and passes it to the nginx container running on port 8080. Nginx encrypts the reply before sending it back through the router to your browser.