From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; rv:0.9+) Gecko/20010523 BuildID: 2001052322 Running a junkbusters proxy on my machine, which is listening at port 8000. Mozilla trunk builds up until about three weeks ago correctly connected to it when setting the proxy manually to localhost and port to 8000 in the prefs. Now, I get a dialog box saying that the specified URL refused the connection. I know the junkbuster proxy is working ok because I can still run Nav 4.76 with similar proxy settings, and it works. Reproducible: Always Steps to Reproduce: 1. In prefs..advanced..proxies, choose manual configuration. 2. Under http, enter localhost and under port, enter 8000. Make sure a junkbusters proxy is running and listening at 8000. 3. Try to reach any web page. Actual Results: Error dialog box saying connection refused. Expected Results: Display web page. Mozilla running on Solaris 2.8/Ultrasparc.
->New I don't use solaris regularly, but if you say it happens, that's enough for me. Can you try localhost.<domain> or some other localhost FQDN that returns 127.0.0.1? Also, can you try 127.0.0.1 as well? benc
Ok, setting proxy to "localhost.<domain>" works. Also, setting it directly to 127.0.0.1 works. I guess the only problem is that syntax that worked in Nav 4.76 which worked up unitl a few weeks ago doesn't work any longer. Maybe there should just be some examples in the dialog box for how to enter proxy host addresses?
No, I think the real problem is that "we" (networking people) need to clarify what we mean by localhost. I'm going to read all the localhost related bugs and post to netlib newsgroup...
plat and OS to all, dupe is for Linux. more troubleshooting details in that bug...
*** Bug 85020 has been marked as a duplicate of this bug. ***
I happens on both Linux and Win32. Changing localhost to 127.0.0.1 seems to fix it. For three weeks now I was thinking a major bug hit Mozilla.
I take that back: on Win32 setting the proxy to 127.0.0.1 works for a time and then all the pages are redirected to localhost:80 or some other weird place. Check the DNS resolver library... it got toasted.
I ran into pretty much the same problem with 10.0.0.1 on port 8000 for my proxy, http and https. New build of Mozilla failed to work with that at all. Old one worked fine, IE works fine. Junkbuster only listens on the internal interface, ordinarily, since I'm not in the business of being an anonymiser for the internet. :)
$ ls -l hosts lrwxrwxrwx 1 nemo None 155 Aug 11 12:18 hosts -> //c/WINDOWS/SYS TEM32/DRIVERS/etc/hosts $ tail -1 hosts 10.0.0.1 internal That fixed things. Thanks for the advice of this bug. Still have no clue why Mozilla is messing that up.
Proxies do work on localhost - I've been doing that for the past couple of weeks at least. Note that junkbuster is totally broken - see bug 38488. That would be the cause of the comments from Aug 1. Marking WFM based on original problem.
Question for Brad. When you say that a localhost proxy works for you, do you have a hosts file entry that resolves "localhost" to 127.0.0.1? Because I don't think this was Junkbuster's fault. It didn't seem that the requests were even making it to the interace Junkbuster was listening on. When I set Junkbuster to listen on all interfaces, Mozilla worked. When it was set to 10.0.0.1 (internal), only IE worked. When I added a hosts file entry of 10.0.0.1 internal Mozilla worked again. I suspect this is a problem in Mozilla (at least in the build I was using), and once I get home I will look for another free proxy (or just write a small script to listen on that port and report what it gets)
VERIFIED: we have two reports of apparently the same problem, with some workaround. I do not know what the root cause is, but I'll deal with that later. Using: netstat -a | grep LISTEN | grep <PORT> Probably you would find that junkbuster ran only on 127.0.0.1:<PORT> (not *:<PORT>). Florin: If you never got your problem w/ DNS dying occassionally, please open a new bug. kyberneticist: I'm not sure how adding a /etc/hosts entry for "internal" would affect the name resolution of "localhost", so if you would like to discuss that, I'd be glad to in a new bug.