Websocket closed, reason: Connection was closed abnormally (that is, with n

Hello,
I have an issue with the websocket when vaadin application running on the server behind NGINX proxy. On the localhost it seems working good.

Issue:
![Link]
(https://i.imgur.com/VE1NX5y.png)

On localhost:
![link]
(https://i.imgur.com/lO7yzvN.png)

Nginx configuration:

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
	listen 80 default_server;
	listen [::]
:80 default_server;

	# SSL configuration
	#
	# listen 443 ssl default_server;
	# listen [::]
:443 ssl default_server;
	#
	# Note: You should disable gzip for SSL traffic.
	# See: https://bugs.debian.org/773332
	#
	# Read up on ssl_ciphers to ensure a secure configuration.
	# See: https://bugs.debian.org/765782
	#
	# Self signed certs generated by the ssl-cert package
	# Don't use them in a production server!
	#
	# include snippets/snakeoil.conf;

	root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;

	server_name xxxxxxxxx xxxxxxxxx;

	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
		return 301 https://$server_name$request_uri;
	}

	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	#	include snippets/fastcgi-php.conf;
	#
	#	# With php-fpm (or other unix sockets):
	#	fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
	#	# With php-cgi (or other tcp sockets):
	#	fastcgi_pass 127.0.0.1:9000;
	#}

	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	#	deny all;
	#}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#	listen 80;
#	listen [::]
:80;
#
#	server_name example.com;
#
#	root /var/www/example.com;
#	index index.html;
#
#	location / {
#		try_files $uri $uri/ =404;
#	}
#}

server {

	# SSL configuration
	#
	# listen 443 ssl default_server;
	# listen [::]
:443 ssl default_server;
	#
	# Note: You should disable gzip for SSL traffic.
	# See: https://bugs.debian.org/773332
	#
	# Read up on ssl_ciphers to ensure a secure configuration.
	# See: https://bugs.debian.org/765782
	#
	# Self signed certs generated by the ssl-cert package
	# Don't use them in a production server!
	#
	# include snippets/snakeoil.conf;

	root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;
    server_name xxxxxxxx xxxxxxxx; # managed by Certbot


#	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
#		try_files $uri $uri/ =404;
#	}

	location / {
	  proxy_pass https://localhost:9200;  
          proxy_http_version 1.1;
          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;
	  client_max_body_size 100M;

	  #websocket
#	  proxy_set_header   X-Forwarded-For $remote_addr;
#	  proxy_set_header   Host $http_host;
#	  proxy_pass         "http://127.0.0.1:4200";
#	  proxy_http_version 1.1;
	  proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";

	}

	location /auth {
	  proxy_pass https://localhost:8443/auth;
          proxy_http_version 1.1;
          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;

	  #websocket
	  proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
	}

	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	#	include snippets/fastcgi-php.conf;
	#
	#	# With php-fpm (or other unix sockets):
	#	fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
	#	# With php-cgi (or other tcp sockets):
	#	fastcgi_pass 127.0.0.1:9000;
	#}

	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	#	deny all;
	#}


    listen [::]
:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/xxxxxxxxxx/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/xxxxxxxxxx/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot



}
server {
    if ($host = xxxxxxxxxx) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = xxxxxxxxxx) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


	listen 80 ;
	listen [::]
:80 ;
    server_name xxxxxxx xxxxxxx;
    return 404; # managed by Certbot




}

Hi,

I don’t know exactly the reason.
You can try to google nginx websocket, that’s probably a “common” problem.

You can also check this link: https://mvysny.github.io/Vaadin8-push-issues/

The solution/theory also works for Vaadin 14.

Jean-Christophe Gueriaud:
Hi,

I don’t know exactly the reason.
You can try to google nginx websocket, that’s probably a “common” problem.

You can also check this link: https://mvysny.github.io/Vaadin8-push-issues/

The solution/theory also works for Vaadin 14.

I was looking for answer in google and haven’t found solution yet. Maybe my english is not enough for this…

Sorry I wasn’t clear enough.

In the link I sent, there are some configuration you can try in Vaadin and also some configurations you can try on your server (timeout, …).

As it said in the beginning of the link: “Vaadin Push is a tricky complicated beast, based on a complicated push stack.”

But I can’t help you more for this particular subject because I don’t know enough about nginx.

Perhaps somebody else will help you.

Jean-Christophe Gueriaud:
Sorry I wasn’t clear enough.

In the link I sent, there are some configuration you can try in Vaadin and also some configurations you can try on your server (timeout, …).

As it said in the beginning of the link: “Vaadin Push is a tricky complicated beast, based on a complicated push stack.”

But I can’t help you more for this particular subject because I don’t know enough about nginx.

Perhaps somebody else will help you.

Ok. Thank you at all :slight_smile: