web-dev-qa-db-ja.com

アップストリームへの接続中にnginx接続が拒否されました

私はAPI（シナトラ）をデプロイしたサーバーを持っています。そのAPIをポート9292で実行し、リクエストをプロキシします。

また、静的なJavaScriptファイルとそのサポートリソースをデプロイする必要があります。同じサーバーでそれを行います。

以下の情報はすべて匿名化されています。

APIアクセスエンドポイントは次のとおりです。

server {
    listen 80;
    server_name api.myapp.com;

    location / {
            proxy_pass http://localhost:9292;
    }
}

そして私がJSを提供しているエンドポイントは：

server {
    listen 80;
    server_name xsa.myapp.com;

    location / {
            root /data/mydir/xsa;
    }
}

以下のエラーで表示される「localhost：3003」サーバーは、JSの参照元です。

2018/11/23 23:31:27 [error] 18720#0: *32 connect() failed 
(111: Connection refused) while connecting to upstream, 
client: 255.255.255.7, server: api.myapp.com,
request: "GET /api/v1/sub/sub_ABCXYZ/info?token%3D56f51132-
406b-4e06-a600-7379876446ed HTTP/1.1", upstream:
"http://[::1]:9292/api/v1/sub/sub_ABCXYZ/info?token%3D56f51132
-406b-4e06-a600-7379876446ed", Host: "api.myapp.com",
 referrer: "http://xsa.myapp.com/src/selector.html?
mfid=sub_ABCXYZ&location=http://localhost:3003/"

要約すると：

  • Sinatra API VM "x" with port 9292
  • VM "x"のnginxサーバーは、 "api.myapp.com"に着信するリクエストに対して、ポート80でAPIにプロキシを提供します
  • 同じnginxサーバーは、「xsa.myapp.com」に着信するリクエストに対してポート80でjavascriptファイルも提供します

私はブラウザでJSをうまく表示できるので、実際に提供されています。エラーを引き起こしているのは、インスタンス化時に行う動的な処理です。

9292のSinatraサーバーが実際に要求を受け取って200を返していることもわかります。問題はこの後のようです。したがって、上流の接続が実際に拒否されているようにも見えません。この返信がJSがローカルで提供されている（そして機能している）場合とまったく同じ応答であることを再確認しました。

*更新*

「接続が拒否されました」エラーは、JSがローカルで提供されて正しく機能している場合でも実際に発生するため、そのエラーはレッドニシンのようです。

nginxjavascriptsinatra
2
AKWF

SinatraアプリケーションがローカルホストのデフォルトIPv6アドレス::1をリッスンしていないため、代わりにレガシーIPv4アドレス127.0.0.1をリッスンしているため、このエラーメッセージが表示されます。

Nginxアップストリームがlocalhostであると指定したため、nginxは最初にIPv6アドレスを試しますが、アプリサーバーがこのアドレスをリッスンしていないため、nginxは接続を拒否します。次に、IPv4での接続を再試行します。接続は成功し、アプリケーションにサービスを提供します。

これによりパフォーマンスの問題が発生し、IPv6は非推奨のIPv4よりも優先されるため、IPv6でリッスンするようにSinatraアプリケーションを再構成する必要があります。例えば、

set :bind, '::1'

特に、12-7.0.0.1にnotをバインドする必要があります。

バインドホストを削除することもできます。これは、デフォルトでIPv6 localhostをリッスンするためです（prodで必要なシン）またはWEBrick（devでは、gem install thinを忘れた場合）。

（そして、関連する注記では、nginxを明示的にnotにリッスンしているため、IPv6でリッスンします。これにより、後で、またはおそらく今でも同様の問題が発生します。 これも修正する必要があります =、それをしている間。）

1
Michael Hampton