Why connection to localhost is refused?

Question

I have a server, to which a client machine connects. Recently I decided to encrypt the connection with stunnel, so now client program connects not directly to the server, but to localhost:8045 (I checked, and this port is not occupied).

Java code:

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

And I get the following:

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

If I try to request the same page using curl, everything is fine.

What can cause such behavior?

EDIT: Yes, there is a listening socket - running netstat -avn | grep 8045 gives:

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

Answer 1

The listening socket is bound to the IPv6 loopback address (::1). I recall some issues with Java not supporting dual-stack IPv4/IPv6 systems correctly; this is probably such a case. It is connecting to 127.0.0.1 only (IPv4).

Everything else you have tried (curl, telnet...) will try the IPv6 address first, and then fall back on the IPv4 address if that fails. That's why they work, while the Java application does not.

Try forcing stunnel to bind to 127.0.0.1. You might also try having Java connect to http://[::1]:8045/malibu/GetProviders, though I can't recall if it supports IPv6 addresses in HTTP URLs.

Answer 2

I have Apache on Windows and also connection refused from Java. However debugging the connection and the Apache log shows, that it is actually not a connection problem. Apache returns error 301, permanently moved. Then it provides a redirection url to non-existing port 8080. So something's wrong with the server configuration, probably ServerName directive uses wrong port. Adding a trailing slash to the requested url fixes the problem. The most useful debugging output in my case was given by wget.

It's possible that the accepted answer does not explain the phenomenon. The reporter himself admitted in a comment that finally he used a url with slash at the end.