Обратный прокси-сервер Websocket с nginx: ошибка запроса в журнале сервера, но работает в браузере

Ситуация

Я использую Etherpad , который проксируется через nginx. Etherpad использует веб-сокеты с Socket.io.

Моя конфигурация nginx более или менее похожа на эту . Блок местоположения для socket.io следующий:

rewrite /CustomSubDir/socket.io/(.*) /socket.io/$1 break;
proxy_pass http://localhost:CustomPort/;
proxy_redirect   / /CustomSubDir/;
proxy_cookie_path / /CustomSubDir/;

# usual proxy header
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-NginX-Proxy true;

# websocket
proxy_set_header Accept-Encoding "";
proxy_http_version 1.1;
# http://nginx.org/en/docs/http/websocket.html
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;

proxy_buffers 8 32k;
proxy_buffer_size 64k;

proxy_buffering off;

Что сбивает с толку

Итак, хорошее сообщение: Основной: хотя все работает, nginx всегда показывает мне сообщения об ошибках.

Что не так

nginx показывает мне эти ошибки в error.log :

2016/05/24 xx:yy:zz [error] 22197#0: *12059 connect() failed (111: Connection refused) while connecting to upstream, client: SOM.IPA.DDR.EES, server: somedomain.example.com, request: "GET /CustomSubDir/socket.io/?EIO=3&transport=polling&t=1464121868147-3&sid=H2GhIY24t2a40etpAACd HTTP/2.0", upstream: "http://[::1]:CustomPort/socket.io/?EIO=3&transport=polling&t=1464121868147-3&sid=H2GhIY24t2a40etpAACd", host: "somedomain.example.com"
2016/05/24 xx:yy:zz [error] 22197#0: *12070 connect() failed (111: Connection refused) while connecting to upstream, client: SOM.IPA.DDR.EES, server: somedomain.example.com, request: "POST /CustomSubDir/socket.io/?EIO=3&transport=polling&t=1464122037998-5&sid=T-pthraR669TF2cKAACe HTTP/2.0", upstream: "http://[::1]:CustomPort/socket.io/?EIO=3&transport=polling&t=1464122037998-5&sid=T-pthraR669TF2cKAACe", host: "somedomain.example.com"

Так что я могу отследить эти запросы вниз . Вот почему: 1. Очевидно, что это запросы Websocket. 2. И это - и это особенные - запросы POST.

При загрузке Etherpad или повторном подключении к нему после потери соединения делается только один запрос, который удовлетворяет этим требованиям. Я четко вижу это в браузере и вижу, как он появляется в журнале ошибок nginx в режиме реального времени. Это запрос в моем браузере:

200 POST https://somedomain.example.com/CustomSubDir/socket.io/?EIO=3&transport=polling&t=1464121868143-2&sid=H2GhIY24t2a40etpAACd

И он содержит (например) эту полезную нагрузку:

164:42["message",{"component":"pad","type":"CLIENT_READY","padId":"CENSORED","sessionID":"null","password":null,"token":"t.qbszmj[...]","protocolVersion":2}]

Ответ сервера:

HTTP/2.0 200 OK
Server: nginx
Date: Tue, 24 May 2016 xx:yy:zz GMT
Content-Type: text/html
Content-Length: 2
access-control-allow-origin: *
Set-Cookie: io=H2GhIY24t[...]
X-Firefox-Spdy: h2

ok

Почему я могу быть уверен, что это виновник

Я очень уверен, что запрос POST вызывает это. Не только потому, что это единственный запрос POST с этим URL-адресом при доступе к панели, я также могу сравнить поведение. Потому что на том же сервере я также запускаю Etherdraw , который работает очень похоже, но имеет одно важное отличие: похоже, он не использует запросы POST Websocket.
И угадайте, что? error.log пуст.

Мои вопросы

Итак, какие у меня вопросы:

  1. Как я могу увидеть успешный запрос в моем браузере (с правильным ответом сервера!) пока nginx сообщает мне об ошибке в журнале?
  2. Как я могу избавиться от этих сообщений об ошибках? AFAIK запросы не терпят неудачу ...
2
задан 1 June 2016 в 21:41
1 ответ

Я смог решить свою проблему благодаря @ webzwo0i , который сообщил мне на GitHub , что это может быть конфликт IPv4 / IPv6.

] Итак, я снова заглянул в журналы ошибок и особенно заметил следующее:

«[...] connect () не удалось (111: соединение отклонено) при подключении к восходящему [...]», восходящему: «http: // [::1 provided:CustomPort/socket.io/[...pting"

) Это адрес локального хоста IPv6, но Etherpad / NodeJS, похоже, подключается только к адресу IPv4.

Таким образом, изменение всех localhost в конфигурации nginx на 127.0.0.1 решило мою проблему. Ошибки в журнале исчезли. Я также заметил, что некоторые другие запросы также вызывали те же ошибки в журнале, поэтому они не относятся к описанным мною запросам.

0
ответ дан 3 December 2019 в 14:27

Теги

Похожие вопросы