Подтвердить что ты не робот

Python - ConnectionError: превышено максимальное количество попыток

Я иногда получаю эту ошибку, когда мой сервер (назовите его сервером 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 - это сервер Python с apache, а сервер B - сервер NodeJS. Я не совсем как мастер веб-сервера, так что кроме этого я не совсем уверен, какая информация будет релевантной.

Кто-нибудь знает, что означает эта ошибка, или как начать расследование исправления? Или кто-нибудь знает, какой сервер, вероятно, будет проблемой, тот, кто делает запрос, или тот, кто его получает?

Изменить: Ошибка также началась с нашими вызовами на внешние веб-ресурсы.

4b9b3361

Ответ 1

Вы получаете сообщение CONN Refused on "some_ip" и порт. Вероятность этого - На самом деле сервер не прослушивает эту комбинацию портов /IP - Настройки брандмауэра, которые отправляют Conn Refused (менее вероятно причина!) - В-третьих - неправильно сконфигурированный (более вероятный) или занятый сервер, который не может обрабатывать запросы.

Я верю Когда - сервер 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. (Примечание: цикл переадресации, как упоминалось выше, неправильно обработанный, может привести к тому, что сервер будет занят, поэтому, возможно, решение может решить вашу проблему)

Ответ 2

Если вы используете gevent на своем сервере python, вам может потребоваться обновить версию. Похоже, что есть только некоторая ошибка с разрешением gevent DNS.

Это обсуждение из библиотеки запросов: https://github.com/kennethreitz/requests/issues/1202#issuecomment-13881265

Ответ 3

Это выглядит как цикл перенаправления на стороне Node.

Вы говорите, что сервер B является сервером Node, вы можете случайно создать цикл перенаправления, если неправильно настроили маршруты. Например, если вы используете экспресс на сервере B - сервере Node, у вас может быть два маршрута и предполагается, что вы сохраняете свою логику маршрута в отдельном модуле:

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);

Тогда ваши маршруты /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);
    }
}

Чтобы определить, является ли это циклом переадресации, вы можете сделать одну из нескольких вещей, вы можете использовать завиток, чтобы получить URL-адрес с теми же параметрами сообщений (при условии, что это сообщение, иначе вы можете просто использовать хром, это будет ошибка в консоли, если она замечает цикл переадресации), или вы можете записать на stdout на сервере или syslog Node внутри маршрута (-ов).

Надеюсь, что это поможет, хорошо, что вы упомянули о "вызванной перенаправлением" части, то есть я думаю, что проблема.

В приведенной выше ситуации используется выражение для описания ситуации, но, конечно, проблема может существовать, используя только соединение, другие фреймворки или даже собственный код обработчика, если вы вообще не используете какие-либо фреймворки или библиотеки. В любом случае, я бы сделал привычкой хорошо проверять параметры и всегда проверять ваши крайние случаи, я столкнулся с этой проблемой именно тогда, когда я спешил в прошлом.