Why is connection with localhost not supported?

Question

I have a server to which a client computer connects. I recently decided to encrypt the connection using stunnel, so now the client program does not connect directly to the server, but to localhost: 8045 (I checked, and this port is not busy).

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 will be fine.

What can cause this behavior?

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

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

Answer 1

The listening socket is bound to the IPv6 loop address (:: 1). I recall some problems with Java that do not support IPv4 / IPv6 dual-stack systems correctly; this is probably the case. It only connects to 127.0.0.1 (IPv4).

Everything else that you tried (curl, telnet ...) will first try the IPv6 address, and then return to the IPv4 address if this does not work. That is why they work while the Java application is not working.

Try applying stunnel to bind to 127.0.0.1. You can also try connecting Java to http://[::1]:8045/malibu/GetProviders , although I cannot remember if it supports IPv6 addresses in HTTP URLs.

Answer 2

I have Apache on Windows, and also the connection refused Java. However, connection debugging and the Apache log show that this is not really a connection problem . Apache returns error 301, constantly moved. It then provides a redirect URL to port 8080 that does not exist. So there is something wrong with the server configuration, perhaps the ServerName directive is using the wrong port. Adding a trailing slash to the requested URL resolves the issue. The most useful debug output in my case was set by wget.

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