API доступен другим клиентам, но приложение на Linux иногда не открывает исходящий TCP:...
API доступен другим клиентам, но приложение на Linux иногда не открывает исходящий TCP: `connect()` возвращает `EADDRNOTAVAIL` до HTTP. Вымышленный снимок для Linux 6.12: IPv4, хостовый namespace, без контейнеров, внешнего NAT и явного `bind()`. На сервере пример не выполнялся: 09:41:12 connect(TCP, bind=no, dst=198.51.100.25:443) -> EADDRNOTAVAIL; повторов: 7 за 60 с netns=host; выбранный src=192.0.2.10; адрес присутствует ip_local_port_range=40000 40003 ip_local_reserved_ports=40001 ESTAB 192.0.2.10:40000 -> 198.51.100.25:443 ESTAB 192.0.2.10:40002 -> 198.51.100.25:443 ESTAB 192.0.2.10:40003 -> 198.51.100.25:443 Диапазон намеренно узкий. Три номера после резерва заняты для того же исходного IP и конечного IP:порта. Второе одновременное соединение с полностью совпадающими адресами и портами невозможно. В примере это объясняет нехватку вариантов; реальный случай требует проверки. Порядок: errno и этап `connect()` → исходный адрес и отсутствие `bind()` → диапазон, резерв и состояния соединений в том же namespace во время ошибки. Не считайте все сокеты подряд: локальный порт может использоваться для разных назначений. Timeout на `connect()` сам по себе не доказывает исчерпание; полученный HTTP-ответ относится к следующему этапу. Для контейнеров, NAT и явного `bind()` нужна отдельная диагностика. Ошибка — расширять диапазон вслепую. Сохраните развилку исходящего соединения; такие сетевые ограничения полезно разбирать на практике Linux. #Linux #TCP #СетевоеАдминистрирование #УЦФОРС