У меня было несколько неудачных вызовов API в мобильном клиенте. Для расследования я последовал совету Джозефа Скотта и выполнил curl с несколькими параметрами отладки:
Результаты с сервера Amazon EC2:
time_namelookup: 0.011
time_connect: 0.011
time_appconnect: 0.016
time_pretransfer: 0.027
time_redirect: 0.000
time_starttransfer: 0.049
----------
time_total: 0.049
Результаты с ноутбука (в Израиле):
time_namelookup: 5.004
time_connect: 5.264
time_appconnect: 5.851
time_pretransfer: 5.851
time_redirect: 0.000
time_starttransfer: 6.188
----------
time_total: 6.188
Мой resolv.conf:
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 192.168.0.1
Другие детали:
dig возвращается мгновенно.Есть идеи, почему поиск time_name занимает так много времени?
Обновить
Когда я выполняю ту же команду в другой беспроводной сети, я получаю следующее:
time_namelookup: 0.003
time_connect: 0.273
time_appconnect: 2.189
time_pretransfer: 2.189
time_redirect: 0.000
time_starttransfer: 3.200
----------
time_total: 3.201
Вероятно, это означает, что долгое time_namelookup действительно была проблема с брандмауэром. Спасибо всем, кто помогал!
Тот факт, что время ожидания составляет пять секунд, может иметь большое значение. Некоторые приложения (но особенно не dig) использовать getaddrinfo() вместо того gethostbyname(); первый, если он вызывается с определенными аргументами, будет ждать ответов как IPv4, так и IPv6, тогда как второй сразу же вернет ответ IPv4. Тайм-аут по умолчанию для getaddrinfo() в данном случае - пять секунд.
Нам действительно нужен tcpdump отслеживать трафик порта 53 с точки зрения ошибочного клиента, чтобы увидеть, что происходит. Я недавно решил такую проблему, и оказалось, что брандмауэр блокировал один из ответных пакетов.
Это macosx, я вижу это в дампе resolv.conf. этот файл используется для совместимости. сервер имен 192.168.0.1 работает правильно? поведение указывает мне, он не работает и обрабатывает таймауты с контактом DNS. другое, 192.168.0.1 - это локальный IP-адрес в немаршрутизируемом классе IP (не маршрутизируемый через Интернет). это должен быть любой DNS-сервер с локальным кешем. это работает? Вы проверяли это с помощью nslookup?
другой момент, в macosx у вас есть файлы / etc / resolver / *. возможно, один инструмент получает конфигурацию из resolv.conf и ожидает тайм-аута, а другой инструмент получает ее из файла / etc / resolver / *. посмотрите, что настроено в этом файле. возможно, вам следует обновить конфигурацию, особенно внутри resolv.conf. не редактируйте это вручную (как описано в комментарии), сделайте любой инструмент macosx.
Я нашел рецепт с разрешением DNS, но не уверен, что он вам подходит: http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/ но, возможно, это вам поможет.