Perché la connessione a localhost viene rifiutata?

Question

Ho un server, al quale si connette una macchina client. Recentemente ho deciso di criptare la connessione con stunnel, quindi ora il programma client si connette non direttamente al server, ma a localhost: 8045 (ho controllato, e questa porta non è occupata).

codice Java:

URL url = new URL("http://localhost:8045/malibu/GetProviders"); 
InputStream stream = url.openStream(); 

e ottengo il seguente:

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) 
    . . . 

Se provo a chiedere la stessa pagina utilizzando curl, è tutto a posto.

Cosa può causare un simile comportamento?

EDIT: sì, c'è un socket in ascolto - in esecuzione netstat -avn | grep 8045 dà:

tcp6  0  0 ::1:8045    :::*     LISTEN 

Answer 1

Il socket di ascolto è legato all'indirizzo di loopback IPv6 (:: 1). Ricordo alcuni problemi con Java che non supportavano correttamente i sistemi dual-stack IPv4/IPv6; questo è probabilmente un caso del genere. Si sta collegando solo a 127.0.0.1 (IPv4).

Tutto il resto che hai provato (arricciatura, telnet ...) proverà prima l'indirizzo IPv6 e poi ricadrà sull'indirizzo IPv4 se fallisce. Ecco perché funzionano, mentre l'applicazione Java no.

Provare a forzare stunnel a collegarsi a 127.0.0.1. Potresti anche provare a connettere Java a http://[::1]:8045/malibu/GetProviders, anche se non riesco a ricordare se supporta gli indirizzi IPv6 negli URL HTTP.

Answer 2

Ho Apache su Windows e anche connessione rifiutata da Java. Tuttavia, il debug della connessione e il registro di Apache mostrano che in realtà è non un problema di connessione. Apache restituisce l'errore 301, permanentemente spostato. Quindi fornisce un url di reindirizzamento alla porta 8080 non esistente. Quindi qualcosa non va con la configurazione del server, probabilmente la direttiva ServerName usa una porta sbagliata. L'aggiunta di una barra finale all'url richiesto risolve il problema. L'output di debug più utile nel mio caso è stato fornito da wget.

È possibile che the accepted answer non spieghi il fenomeno. Lo stesso reporter ha ammesso in un commento che alla fine ha usato un url con una barra alla fine.