Issue Can curl remotely, but not locally on Plesk server. Always Get curl: (7) couldn't connect to host

[yabado]

When I try to curl a site hosted on my Plesk server, FROM my Plesk server, it always fails with "curl: (7) couldn't connect to host".

This is not a firewall issue, but possibly an issue what nginx Listens for?

It works if I curl from my remote desktop, but not if I try and curl locally.

Could it be that it is not listening for local curl connections and only remote ones?

If so, then how can I fix this?

Thanks.

 

[Monty]

* What exact command do you enter?
* Have you tried this:

# telnet your.plesk-domain.tld 80

* What's the output/error message of this?
* Which DNS servers are configured in /etc/resolv.conf?
* Do these DNS servers have the correct DNS data for your domain? Test it with dig or nslookup

 

[yabado]

Telnet give a similar error...

$ telnet your.plesk-domain.tld 443
Trying 54.191.0.0...
telnet: connect to address 54.191.0.0: Connection refused

So you can see it is not a DNS issue, since it know which IP to target.

 

[Monty]

(I assume this IP is an example/redacted IP, right?)

So, you get a "Connection refused" when you try to connect to port 443 on your IP. This basically means you either have no service running on that port (check output of "netstat -tulpen") or you may have a firewall rule that rejects the connection.

 

[yabado]

Yes the IP is redacted.

No it is not a firewall issue. As pointed out in my original post, I can connect via curl on remote machine ( different than server ) but cannot connect when on the server itself.

I am wondering if the Listen config for nginx is not using the wildcard? Like Listen *:443

Where is the config file that I can check? Or if there a way to make all hosts use *:443 ?

 

[Monty]

What's the output of:

# netstat -tulpen

 

[yabado]

There were many lines to the results, but here is the one you are likely interested in...

tcp        0      0 10.0.0.144:443              0.0.0.0:*                   LISTEN      0          20664      7602/nginx

The 10.0.0.144 IP is internal part of VPC on my EC2 instance.

 

[Monty]

Ah, you have internal IPs on your server? Well, that's kind of important information...
So I assume "telnet 10.0.0.144 443" works, but the same doesn't work if you use your public IP.

I have no experience with EC2 VPC, but I guess you'll have to check your network config (especially firewall rules) on the host where your public IP is.
And just to make sure, did you follow the steps here?

Running Plesk Behind a Router with NAT

If your Plesk server is behind NAT, you can match private IP addresses on the server to the corresponding public IP a...

docs.plesk.com

 

[yabado]

Ah, you have internal IPs on your server? Well, that's kind of important information...
So I assume "telnet 10.0.0.144 443" works, but the same doesn't work if you use your public IP.

I have no experience with EC2 VPC, but I guess you'll have to check your network config (especially firewall rules) on the host where your public IP is.
And just to make sure, did you follow the steps here?

Running Plesk Behind a Router with NAT

If your Plesk server is behind NAT, you can match private IP addresses on the server to the corresponding public IP a...

docs.plesk.com

Yes. The IP Addresses are all setup correctly and working well.

All services on server work great, it's just the internal telnet and curl requests that are choking.

 

[Monty]

Yes but your problem is this:
You connect from your internal IP 10.0.0.144 to your public IP 54.191.x.x which is translated back via NAT to your internal IP again. And this connection fails.
This is most likely due to the host that owns your public IP doesn't allow this kind of connection.
Which host owns your public IP? I'm pretty sure it's a firewall issue and not a Plesk issue. Maybe check with Amazon support, i'm sure they can help you.

 

[exit15]

Had the same issue, curl not working only for the domain that was also set-up as the domain name of the server. The problem is that some hosts create the Plesk droplet/instance/image, or whatever they call it, pointing the server's domain name to an internal IP address. This can be seen etc/hosts. I guess this record takes precedence over the individual domains configs that are found in /etc/nginx/plesk.conf.d/vhosts.

So if your etc/hosts has
127.0.0.1 localhost
127.0.1.1 exampledomain.com -- Change this record to the external IP address and reboot.

Now, when you ping from within the server you will get a response from the external IP and CURL will not hit a wall.

 

[mow]

This can be seen etc/hosts. I guess this record takes precedence over the individual domains configs that are found in /etc/nginx/plesk.conf.d/vhosts.

/etc/hosts is for the local DNS resolver used by DNS client requests. Plesk configurations will affect what IPs the services listen on and what the DNS server will answer (though in such a setup, there will probably another server for requests from outside, not plesk's). hosts is usually checked first, as the default for /etc/host.conf is

order hosts, bind

, and then the nameservers as configured in /etc/resolv.conf.

So if your etc/hosts has
127.0.0.1 localhost
127.0.1.1 exampledomain.com -- Change this record to the external IP address and reboot.

1) no reboot required, changes in /etc/hosts will be picked up by the resolver immediately
2) 127.x.x.x is not an internal/local IP address (10.x.x.x, 172.x.x.x or 192.168.x.x) but the loopback IP address.
3) OP already wrote that their domain resolves to the external IP 54.191.x.x so your proposed change would have the same result.
4) There probably is no line with exampledomain.com in /etc/hosts, or if there is, it points to the external IP.
5) So /etc/hosts needs to have a line that points exampledomain.com to the local IP:
10.0.0.144 exampledomain.com

Now, when you ping from within the server you will get a response from the external IP and CURL will not hit a wall.

ping would probably work anyway, as ping does not require any forwarding back (backwarding?) to the local host by the NAT.
But curl will still hit a wall.

 

[exit15]

It worked! What can I say, if you have the same problem, it might work for you too.

 

[safemoon]

Did anyone find a solution yet? I have the same issue, can't do curl request for the REST API from the same server. I get connection refused error

 

[mow]

Did anyone find a solution yet? I have the same issue, can't do curl request for the REST API from the same server. I get connection refused error

Do you have NAT too?