Resolved: Firewall blocks Winamp from connecting to http://localhost:8001

this is my first posting in this forum, I was unable to find an answer to my problem.
I would like Winamp to be able to connect to the Winamp Streamripper plugin on localhost:8001 again - this used to work in Comodo V2.
My setup is WinXP SP2. I was previously using Comodo FW V2. With this combination I was able to listen and record streaming music with Winamp and the Streamripper plugin (from at the same time using only ONE stream.
To save internet bandwith you can have the Streamripper plugin create a ‘relay’ stream on localhost:8001 which Winamp then can connect to. It is then the Streamripper plugin which gets the music, records it and passes it on to Winamp for listening.
Now with my Comodo FW V3 I’m unable to make Winamp connect to 8001. I would like to save bandwith and still be able to record music.
Following is a screenshot of Winamp and the Streamripper plugin and the FW settings for both.
There’s a link top left in the Streamripper interface named RLY. When this is pressed a relay is created with the address localhost:8001 which shows up in the Winamp playlist here at #3. At #3 it says ‘connecting’ (to the relay stream) which always fails.
Now if I disable the firewall connecting does work. Reenabling the firewall will disallow any further connection attempts, so I am quite sure the problem lies within the firewall settings.
Any help with this is greatly appreciated, thanks.

My firewall settings for Winamp and the Winamp Streamripper plugin

Welcome to the forum Hugo Z. Hackenbush :slight_smile:
You might have to create Gobal rule for incoming.
Please check your firewall logs.

Thanks Dennis2.
Instead of experimenting with a new Global Rule I simply cleared all Global Rules and clicked apply - still no connection.
I also tried putting the firewall into Training Mode clicked apply, started Winamp again and tried to connect to localhost:8001 but again - nothing.
I had Comodo log Unmatching Requests for Winamp but nothing ever showed up in the logs.
I created a top ask rule to have Winamp ask every time. It won’t ask for this special connection attempt!
I used Predefined/Trusted Application for Winamp & Streamripper - still nothing.
Actually “Trusted” for both Winamp & Streamripper and No Global Rules should have done the trick.
I’m still wondering why there had been no problem with Comodo FW V2
Thanks but now I give up.

Issue is Resolved :slight_smile:
I had a forgotten adblock for (which resolves to DoubleClick in New York) in My Blocked Network Zones whick kept Winamp connect to localhost:8001 ???
Too bad you can’t put comments into My Blocked Network Zones. so I had to rely on trial and error to find the culprit.
I would assume that connecting to a relay stream created by Streamripper which has already established its own connection is an ‘internal affair’ and no further outside connection is required. Nothing related to this shows in Active Connections.
When I removed this block I was able to connect again, so I can listen and record again using only the bandwith of a single stream.
Why the blocking of prevents this connection I can’t tell as nothing shows up in the logs but I’m happy to have this functionality back.

I just wanted to say THANK YOU for this thread - I’ve had a similar problem that’s been driving me nuts for MONTHS, being unable to use any applications that employ a loopback connection to a listener port on localhost (

I also thought you or anyone else who stumbles upon this may appreciate the root cause I discovered. Like you, I had a Blocked Network Zones entry for a particular server. What I had forgotten was that I previously added a “blackhole” entry to my hosts file, pointing that hostname to I suspect you may have had the same problem - blocking an undesirable server via a hosts file entry, and then adding that server by name to a Blocked Network Zones entry, causes the server’s “fake” IP ( to be blocked as a result.

Thanks again for saving the remaining hair I haven’t yet pulled out! O0


P.S. I also don’t know why these blocked connection attempts weren’t showing up anywhere in the firewall logs - had they been there, this would have been trivial to troubleshoot, instead of the maddening ordeal it was.

Thanks for your reply. Glad this helped fixing your problem.
Meanwhile I had to remove 4 other hosts from My Blocked Network Zones (MBNZ) to reclaim functionality.
I have NO duplicates in HOSTS, so this is not an issue. I use a downloaded custom HOSTS file to block ads and rogue sites. This never caused any problems.
Actually HOSTS is not a real block but rather a detour or black hole, as you say. With this requests are redirected to
BUT: itself is not blocked by Comodo. It is explicitly enabled as loopback in My Network Zones (MNZ)
Now, if I add an address to MBNZ it should just be blocked, nothing else. And it should not have anything to do with loopback 127.0.01. The blocked addresses in MBNZ do not belong to the loopback range.

My problem was:

  1. the Winamp-plugin can connect to the internet without diffilculty - it is NOT blocked !
  2. but the Winamp-plugin cannot communicate with Winamp because Comodo blocks this !
  3. both Winamp and the Plugin have access full access rights to connect (including loopback)
  4. I must remove unrelated addresses from MBNZ to repair communication between Winamp and it’s plugin

It’s crazy and I don’t understand it. But I’m happy I resolved this issue with MBNZ. It’s probably a bug, so I’d better just put everything into HOSTS from now on instead of relying on MBNZ.

Cheers ;D
PS: you write “…causes the server’s “fake” IP ( to be blocked as a result”. Are you sure Comodo would not just simply block an originating request for any (in MBNZ) blocked’s in the first place. Why do an unneccesary DNS lookup?


As far as the “unnecessary DNS lookup” goes, I think your question really exposes the heart of the problem: name resolution is not unnecessary, and hosts file-based name resolution can cause unintended consequences (as it did for us). Comodo, like other packet-filtering firewalls, doesn’t actually care about host names internally - its underlying rules all operate based on IP address, IP protocol (TCP, UDP, etc.), and port number. The fact that its user interface allows us to use host names instead of numeric IPs is simply a convenience, to make things more human-readable.

Now, here’s where the problem occurs. If you add an entry in Comodo’s “My Blocked Network Zones” for, say,, the underlying firewall rule will actually be based on the numeric IP address for that name (currently, ). Normally, this is fine, and behaves exactly how you’d expect. However, if you also add an entry to your hosts file, pointing to as a “blackhole” address, here’s what happens:

As you can see, this would have the unintended side effect of also blocking desired loopback connections to localhost ( It gets even worse, as you noticed, when you have a bunch of these “blackhole” entries in your custom hosts file. Whenever you have a name in your hosts file pointing to, and that name is also in Comodo’s MBNZ, it will result in Comodo blocking all traffic to - not just for that particular name.

The solution, as you discovered, is simply to avoid duplication between MBNZ entries and hosts file “blackhole” ( entries. There’s nothing wrong with using either one of them to block a particular host, just don’t use both for the same one.

Hopefully, this helps you better understand what was going on, and how the configuration changes you made actually fixed the problem… ;D