I've been trying to use HTTPS whenever I do sensitive web browsing through a proxy server. Ideally I use a combination of HTTPS, an anonymous or elite proxy, and DuckDuckGo for all my web searches. Recently I encountered a problem with this though. Up until now, I've had no problem forcing HTTPS when I connect to a proxy, but just now I started getting a "400: Connection Refused" error when I do this. I used NMap to see which ports were open on the proxy.

sudo nmap -p 1-1024 -sX
Nmap scan report for
Host is up (0.092s latency).
All 1024 scanned ports on are open|filtered

Nmap done: 1 IP address (1 host up) scanned in 96.98 seconds

So all ports are open, including 443, so I should be able to do it. I got this error for every proxy I tried, so it seems to be a problem at my end. The NMap output suggests that it may have something to do with the firewall. Also, I was able to telnet to port 80 but not 443.

So basically my question is, why is this happening, and how do I resolve it?

1 Answer 1


I'm guessing you're using an anonymous proxy and this isn't something you or your company are in control of. If so, you really are at the mercy of the configuration of that server. Your nmap output is also not something I would take to heart, a system with 1,024 ports open is unrealistic.

All 1024 scanned ports on are open|filtered

I'm pretty sure you're traffic is being filtered somewhere along the line which is breaking nmap. Also, a Xmas scan isn't something I would suggest using unless you have specific use for it, stick to something like a TCP scan (-sS) or even a connect() scan (-sT). It very well may be that your scan is lighting up some appliance along the way and it's dropping packets thinking the traffic is bogus.

An HTTP 400 is a bad request. This could be something incorrect in your transmission, like an invalid header, or it could be that the server doesn't speak in HTTPS and you're trying to talk to an HTTP only server using HTTPS. You would likely need to look at the Proxy access logs for more information on the 400. You might have something locally if you can enable debug logging, maybe even a packet trace.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .