SexyHair, он не игнорируется, просто используется вместо системного как вышестоящий ресолвер.
Тут нюанс в том, что докер позволяет переопределить DNS только в дефолтной сетке (bridge docker0). В остальных эта опция означает DNS-сервер, в который docker resolver пересылает запросы, причём этот resolver нельзя убрать. docker-compose на проекст создаёт собственную отдельную сеть.
127.0.0.11 - это docker resolver, DNS в контейнере, я уже говорил, что он большинство запросов проксирует в следующий DNS
127.0.0.53 - это systemd resolved
В выводе systemd-resolve написано, что реальный DNS - 192.168.1.1. Если это дома, то скорее всего DNS в роутере, такой тоже может работать как-нибудь странно.
Предлагаю для сравнения создать контейнер с DNS например от гугла (docker run --dns 8.8.8.8) и проверить, будет ли разница. В общем, попытаться как-то локализовать источник.
SexyHair, я бы проверил что все указанные в resolv.conf (или в resolved) DNS-сервера нормально работают.
Система использует /etc/resolv.conf. Если там указан 127.0.0.53 - это systemd-resolved, нужно смотреть реальные DNS в выводе команды systemd-resolve --status. Ещё можно переопределить DNS в конфигурации докера, в том числе через параметры docker run или в файле для docker-compose, но это вряд ли.
Можно попробовать оставлять один-единственный DNS в /etc/resolv.conf и проверять скриптом на хосте, так выявить, действительно ли конкретный DNS тормозит (а может и вообще не работает?).
MTU тут ни при чём, докеру хватает такого же MTU, как на выходном интерфейсе хоста, а там скорее всего обычные 1500. Более того, при нехватке MTU были бы не редкие задержки, а частые фрагментации пакетов в любых коннектах вне зависимости от использования/неиспользования session.
Скорее проблема в DNS. Если попробовать тестовые запросы делать по IP - проблема уйдёт?
В докере DNS работает так: есть собственный ресолвер, который ресолвит контейнеры по именам, а весь остальной трафик пересылает в штатные DNS, указанные в /etc/resolv.conf, либо в явно указанные в конфигурации контейнера. Если, например, с каким-то из вышестоящих DNS бывают проблемы, когда на него попадаешь, то таймауты вполне объяснимы.
Могу сказать, например, что в некоторых банках номер 79000000000 может быть указан у десятков разных клиентов. Плюс этот номер могут указывать разработчики для тестов или какие-нить умники на всяких сайтах вместо реального номера пишут такую отсебятину. А самое смешное, что этот номер реально существует и принадлежит живому человеку.
Владимир Коротенко, во всё это нужно вкладывать постоянные обновляемые усилия, на которые небольшие сайты, часто делаемые один раз без постоянной тщательной поддержки, не очень-то готовы. В конце концов, многие реально не готовы платить существенные суммы за смс.
В то же время можно просто впендюрить регистрацию через соцсети и фактически переложить проблему левых аккаунтов на них.
makaron710, ага, я помню времена, когда открываешь пять интересных роликов ютуба во вкладках и они одновременно начинают играть, ну просто дико бесило.
Сергей Афанасьев, я, как и все другие комментаторы, не догадался посмотреть официальную доку :) Правильный ответ: при передаче заранее загруженного файла через file_id лимита нет.
Тут нюанс в том, что докер позволяет переопределить DNS только в дефолтной сетке (bridge docker0). В остальных эта опция означает DNS-сервер, в который docker resolver пересылает запросы, причём этот resolver нельзя убрать. docker-compose на проекст создаёт собственную отдельную сеть.