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

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

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

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

3 Solutions collect form web for “Python – ConnectionError: превышено максимальное количество попыток”

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

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

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

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

Это похоже на цикл перенаправления на стороне узла.

Вы указываете, что сервер B является узловым сервером, вы можете случайно создать цикл перенаправления, если неправильно настроили маршруты. Например, если вы используете экспресс на сервере 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 на сервере Node или syslog вне маршрута (-ов) нарушения.

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

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

  • Торнадо или Django работает с CGI?
  • Сценарий Python отправляет изображение на PHP
  • Как копировать / клонировать виртуальную среду с сервера на локальную машину
  • CherryPy с Cheetah как плагин + инструмент - пустые страницы
  • Как веб-сервер python преодолевает GIL
  • OSError: Плохой дескриптор файла в python 3
  • Замена nginx на uwsgi
  • Служба uwsgi не запускается
  • Python - лучший язык программирования в мире.