Почему отказано в подключении к localhost?
у меня есть сервер, к которому клиент подключается машина. Недавно я решил зашифровать соединение с stunnel, поэтому теперь клиентская программа подключается не напрямую к серверу, а к localhost:8045 (я проверил, и этот порт не занят).
Java-кода:
URL url = new URL("http://localhost:8045/malibu/GetProviders");
InputStream stream = url.openStream();
и я получаю следующее:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
. . .
если я попытаюсь запросить ту же страницу, используя curl
, все нормально.
что может вызвать такое поведение?
EDIT: Да, есть прослушивающий сокет-работает netstat -avn | grep 8045
выдает:
tcp6 0 0 ::1:8045 :::* LISTEN
2 ответов
прослушивающий сокет привязан к обратному адресу IPv6 (:: 1). Я вспоминаю некоторые проблемы с Java, не поддерживающей двухстековые системы IPv4/IPv6 правильно; это, вероятно, такой случай. Он подключается только к 127.0.0.1 (IPv4).
все остальное, что вы пробовали (curl, telnet...) сначала попробует адрес IPv6, а затем вернется на адрес IPv4, если это не удастся. Вот почему они работают, а приложение Java-нет.
попробуйте заставить stunnel привязаться к 127.0.0.1. Вы также можете попробовать подключить Java к http://[::1]:8045/malibu/GetProviders
, хотя я не могу вспомнить, поддерживает ли он IPv6-адреса в HTTP-адресах.
У меня Apache на Windows, а также соединение отказано от Java. Однако отладка соединения и журнала Apache показывает, что это на самом деле не проблема подключения. Apache возвращает ошибку 301, постоянно перемещенную. Затем он предоставляет URL-адрес перенаправления на несуществующий порт 8080. Так что что-то не так с конфигурацией сервера, вероятно, директива servername использует неправильный порт. добавление косой черты к запрошенному url исправляет проблему. Наиболее полезный отладочный вывод в моем случае был предоставлен wget.
возможно, что принято отвечать не объясняет явление. Сам репортер признался в комментарии, что в конце концов он использовал url-адрес со слэшем в конце.