11

サーバー(サーバーAと呼びます)が別のサーバー(すべてサーバーB)のリソースにリクエストを送信すると、このエラーが発生することがあります。

ConnectionError: HTTPConnectionPool(host='some_ip', port=some_port): Max retries exceeded with url: /some_url/ (Caused by : [Errno 111] Connection refused)

例外のメッセージは、
message : None: Max retries exceeded with url: /some_url/ (Caused by redirect)
その余分な情報があるため、私が含めたもの(caused by redirect)です。

私が言ったように、私はこのリクエストに関係する両方のサーバーを制御しているので、どちらかまたは両方に変更を加えることができます。また、エラーは毎回発生するわけではないという点で、断続的に発生しているように見えます。

関連する可能性のある情報-サーバーAはApacheを実行しているPythonサーバーであり、サーバーBはNodeJSサーバーです。私は正確にはWebサーバーウィザードではないので、それを超えて、どの情報が関連するのか正確にはわかりません。

このエラーが何を意味するのか、または修正を調査する方法を正確に知っている人はいますか?または、どのサーバーが問題である可能性が高いか、要求を行っているサーバー、または要求を受け取っているサーバーを誰かが知っていますか?

編集:外部Webリソースへの呼び出しでもエラーが発生し始めました。

4

3 に答える 3

2

「some_ip」とポートで拒否された CONN を取得しています。その原因として考えられるのは、 - そのポート/IP の組み合わせを実際にリッスンしているサーバーがない - Conn を送信するファイアウォール設定が拒否された (原因である可能性は低い!) - 3 番目 - 構成が間違っている (可能性が高い) またはビジー状態のサーバーで、要求を処理できない。

私はいつだと思いますか-サーバーAがサーバーBに接続しようとしているときに、そのエラーが発生しています。(Linux および/または UNIX の派生物であると仮定して) netstat -ln -tcp はサーバー上で何を示しますか? (フラグを理解するための man netstat - ここで行っているのは、どのすべてのプログラムがどのポートでリッスンしているかを見つけようとすることです)。それが実際にサーバーBがリッスンしていることを示している場合- iptables -L -n ファイアウォールルールを表示します。そこに何も問題がない場合は、リッスン キューの設定が間違っている可能性があります。( http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/023/2333/2333s2.html ) または google でバックログをリッスンします。

これはおそらく、サーバー B の不適切な構成の問題です。

于 2013-12-14T03:49:51.503 に答える
1

Python サーバーで gevent を使用している場合は、バージョンのアップグレードが必要になる場合があります。gevent の DNS 解決にバグがあるようです。

これはリクエスト ライブラリからのディスカッションです: https://github.com/kennethreitz/requests/issues/1202#issuecomment-13881265

于 2014-03-08T18:58:46.993 に答える
-1

これは、Node 側でのリダイレクト ループのように見えます。

サーバー B がノード サーバーであると述べた場合、ルートを正しく設定しないと、誤ってリダイレクト ループが作成される可能性があります。たとえば、サーバー B (ノード サーバー) で Express を使用している場合、2 つのルートがあり、ルート ロジックを別のモジュールに保持するとします。

var routes = require(__dirname + '/routes/router')(app);
//... express setup stuff like app.use & app.configure
app.post('/apicall1', routes.apicall1);
app.post('/apicall2', routes.apicall2);

次に、routes/router.js は次のようになります。

module.exports = Routes;

function Routes(app){
    var self = this;
    if (!(self instanceof Routes)) return new Routes(app);
    //... do stuff with app if you like
}

Routes.prototype.apicall1 = function(req, res){
    res.redirect('/apicall2');
}
Routes.prototype.apicall2 = function(req, res){
    res.redirect('/apicall1');
}

その例は明らかですが、これらのルートのいくつかの条件の中にリダイレクト ループが隠されている可能性があります。問題のルート内の条件の最後に何が起こるか、たとえば呼び出しに適切なパラメーターがない場合のデフォルトの動作は何ですか?例外の動作は何ですか?

余談ですが、node-validator ( https://github.com/chriso/node-validator ) のようなものを使用して、間違ったリクエストまたは投稿パラメーターを特定して処理することができます。

// Inside router/routes.js:
var check = require('validator').check;

function Routes(app){ /* setup stuff */ }

Routes.prototype.apicall1 = function(req, res){
    try{
        check(req.params.csrftoken, 'Invalid CSRF').len(6,255);
        // Handle it here, invoke appropriate business logic or model, 
        // or redirect, but be careful! res.redirect('/secure/apicall2');
    }catch(e){
        //Here you could Log the error, but don't accidentally create a redirect loop
        // send appropriate response instead
        res.send(401);
    }
}

リダイレクト ループであるかどうかを判断するには、curl を使用して、同じ投稿パラメーターで URL をヒットできます (投稿であると仮定します。それ以外の場合は、chrome を使用するだけでエラーが発生します)。リダイレクト ループに気付いた場合はコンソール)、またはノード サーバーの stdout に書き込むか、問題のあるルート内で syslog アウトすることができます。

「リダイレクトが原因」の部分について言及されたのは良いことです。それが問題だと思います。

上記の例では状況を説明するために Express を使用していますが、もちろん、フレームワークやライブラリをまったく使用していない場合は、接続、他のフレームワーク、または独自のハンドラー コードを使用しても問題が発生する可能性があります。いずれにせよ、適切なパラメーター チェックを行い、常にエッジ ケースをテストすることを習慣にしています。過去に急いでいたときに、まさにこの問題に遭遇しました。

于 2013-06-15T15:01:24.597 に答える