Socket.io с Sails.js/Node.js и NGINX по SSL: плохой шлюз
Я только начал рисковать в NGINX и SSL.
Использование Ubuntu 16.04.
Я запускаю сервер Sails на стандартном порту 1337 и просто настраиваю NGINX с SSL (используя letsencrypt). Порт 80 перенаправлен на 443, а восходящий идет на паруса.
У меня также есть сервер Tomcat, прослушивающий 8080 и использующий NGINX для перенаправления таким же образом.
Все работает отлично: я могу просматривать оба сервера по https без специальных портов в браузере.
Я настроил socket.io для использования только протокола websockets (без опроса). Это устанавливается на сервере и в клиенте браузера.
Однако socket.io (sails.io) выдает ошибку 502 без браузера. (опрос тоже дал ошибку)
Вот мои сайты NGINX, доступные для сервера Sails:
upstream sails {
server 127.0.0.1:1337 fail_timeout=0;
}
server {
listen 80;
listen [::]:80;
server_name mysails.server.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443;
listen [::]:443 ssl http2;
server_name mysails.server.com;
include snippets/ssl-mysails.server.conf;
include snippers/ssl-params.conf;
large_client_header_buffers 8 32k;
location / {
proxy_pass http://sails/;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header Port $server_port;
proxy_set_header X-Real-IP $remot_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass_request_headers on;
}
location /socket.io/ {
proxy_pass http://sails/;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header Port $server_port;
proxy_set_header X-Real-IP $remot_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass_request_headers on;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffers 8 32k;
proxy_buffer_size 64k;
}
}
snippets/ssl-mysails.server.conf
а также snippers/ssl-params.conf
файлы содержат:
ssl_certificate /path/to/letsencrypt/fullchain.pem;
ssl_certificate_key /path/to/letsencrypt/privkey.pem;
а также
# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now. You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Кто-нибудь знает, что происходит...?
ОБНОВЛЕНИЕ ОШИБКИ LOG и странное поведение
Мой журнал ошибок nginx говорит это:
upstream prematurely closed connection while reading response header from upstream, client: XXXXXXXX, server: mysals.server.com, request: "GET /socket.io/?__sails_io_sdk_version=0.13.8&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=websocket HTTP/1.1", upstream: "http://127.0.0.1:1337/?__sails_io_sdk_version=0.13.8&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=websocket", host: "mysails.server.com"
И мой подробный журнал Sails противоречив. Можно сказать так:
*verbose*: Rendering view: "homepage" (located @ "/opt/FillForm/views/homepage")
*verbose*: • using configured layout:: layout (located @ "/opt/FillForm/views/layout")
*verbose*: Rendering view: "homepage" (located @ "/opt/FillForm/views/homepage")
*verbose*: • using configured layout:: layout (located @ "/opt/FillForm/views/layout")
*verbose*: Rendering view: "fileLink" (located @ "/opt/FillForm/views/fileLink")
*verbose*: • using configured layout:: layout (located @ "/opt/FillForm/views/layout")
*verbose*: Sending 404 ("Not Found") response
*verbose*: Sending 404 ("Not Found") response
*verbose*: Rendering view: "fileLink" (located @ "/opt/FillForm/views/fileLink")
*verbose*: • using configured layout:: layout (located @ "/opt/FillForm/views/layout")
*verbose*: Sending 404 ("Not Found") response
*verbose*: Sending 404 ("Not Found") response
Что странно, потому что должен быть только один запрос к /opt/FillForm/views/fileLink
Просмотр страницы.
Если вы обновите страницу (F5), консоль Javascript в браузере может просто сказать:
Socket is trying to reconnect to Sails...
_-|>_- (attempt #7)
и каждая попытка приводит к серии
verbose: Rendering view: "homepage" (located @ "/opt/FillForm/views/homepage")
verbose: • using configured layout:: layout (located @ "/opt/FillForm/views/layout")
сообщения в подробном журнале Sails. Почему запросы сокетов заставляют Sails отображать домашнюю страницу?
Если вы обновляете с игнорированием кеша (shift+F5), консоль Javascript начинает показывать попытку И сообщение 502 неверного шлюза:
WebSocket connection to 'wss://mysqils.server.com/socket.io/?__sails_io_sdk_version=0.13.8&__sails_io_s…tform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 502
Socket is trying to reconnect to Sails...
_-|>_- (attempt #20)
А подробный журнал Sails просто показывает два экземпляра следующего сообщения:
verbose: Sending 404 ("Not Found") response
verbose: Sending 404 ("Not Found") response
И он перестает показывать любые другие ошибки (не как в предыдущем сценарии, где каждая попытка веб-сокета приводила к просмотру сообщений рендеринга).
В этом случае кажется, что запросы wss не проходят через Nginx в Sails.
1 ответ
Таким образом, проблема заключается в неправильной конфигурации файла конфигурации NGINX sites-avalable.
location /socket.io/ {
proxy_pass http://sails/;
...
}
должно быть
location /socket.io/ {
proxy_pass http://sails/socket.io/;
...
}
Довольно простые вещи: "местоположение" не пересылается на proxy_pass (почему это так, правда?) - поэтому вам нужно убедиться, что запросы сокетов перенаправлены на конечную точку сокета.