Using the latest version of Testcafe...
I'm behind a corporate proxy. Using --proxy myproxy:proxyport works fine. but when I try to use localhost, it continually responds with service not available. I have now added --proxy-bypass localhost:8080. But that has the same result.
Has anyone else experienced issues with Testcafe behind a corporate proxy -- and using localhost?
It is likely that localhost:8080 is incorrect. You need to set up your own port here.
In addition, you can simply use the following record:
--proxy-bypass localhost
In this case, all localhosts will be ignored regardless of the port.
Related
What I'm Trying to Achieve
To access localhost from my local machine during the development of a Symfony web app.
My Environment
WSL2 running on Windows 10
Linux, Apache2, MySQL, PHP-7.4 stack (with Xdebug3 intalled)
Debian 10
Symfony 5.4 (although not sure on if relevant to this problem)
Steps I've Taken
Set up WSL2 according to this Microsoft WSL2 tutorial
Set up LAMP stack according to this Digital Ocean tutorial
Set up Symfony according to this Symfony tutorial
Run the following bash script on startup to start my services and set the host to the virtual WSL IP in my xdebug.ini file
#!/bin/sh
REMOTEIP=`cat /etc/resolv.conf | grep nameserver | sed 's/nameserver\s//'`
sed -i -E "s/client_host=[0-9\.]+/client_host=$REMOTEIP/g" /etc/php/7.4/mods-available/xdebug.ini
service php7.4-fpm start
service apache2 start
service mysql start
Run my Symfony project on the development server using symfony serve -d (Symfony then tells me "The Web server is using PHP FPM 7.4.23 https://127.0.0.1:8000")
Go to https://localhost:8000/ in Chrome where the app is running
What I Expect to Happen
My Symfony web app to be running on https://localhost:8000/ when I visit the URL in my Chrome browser
What Actually Happens
I get "This site can't be reached localhost refused to connect." in the Chrome browser
What I've Tried
This used to happen less frequently and I would give my laptop a restart, repeat the process above, and I could connect via https://localhost:8000/. However, it refuses to connect more regularly now (like 8/10 times I start up for the day)
Connecting to https://127.0.0.1:8000 yields the same result.
Connecting to the site using the internal WSL IP address, found using hostname -I and replacing localhost with this IP (still on port 8000). This is an adequate workaround to use my app, however I am unable to interact with my database via MySQL Workbench without having to set up a new connection, therefore a fix where I can use localhost would be very helpful!
(Based off comments) Only ran symfony serve -d without starting apache and PHP services separately - still sometimes allows connections to localhost but sometimes doesn't work.
Conclusion
The behaviour is odd as it works sometimes but other times it doesn't when the exact same steps are carried out. I am unsure where else to look for answers and I can't seem to find anything online with this same problem. Please let me know if any config files, etc would be helpful. Thank you so much for your help! :)
When it's working normally, as you are clearly aware, the "localhost forwarding" feature of WSL2 means that you can access services running inside WSL2 using the "localhost" address of the Windows host.
Sometimes, however, that feature breaks down. This is known to happen when you either:
Hibernate
Have the Windows "Fast Startup" feature enabled (and it is the default). Fast Startup is a pseudo-hibernation which triggers the same problem.
Typically the best solution is to disable Hibernation and Fast Startup. However, if you do need these features, you can reset the WSL localhost feature by:
Exiting any WSL instances
Issuing wsl --shutdown
Restarting your instance
It's my experience that localhost forwarding will work after that. However, if it doesn't, thanks to #lwohlhart in the comments for mentioning that another thing to try is disabling IPv6 on WSL2, since (I believe) there's a possibility that the application is listening on IPv6 while the Windows->WSL2 connection localhost connection is being attempted on IPv6.
You can disable IPv6 on WSL2 per this Github comment by creating or editing .wslconfig in your Windows user profile directory with the following:
[wsl2]
kernelCommandLine=ipv6.disable=1
A wsl --shutdown and restart will be necessary to complete the changes.
If you find that this works, it may be possible to solve the issue by making sure to either use the IPv4 (127.0.0.1) or IPv6 (::1) address specifically in place of localhost on the Windows side, or by configuring the service to listen on both addresses.
Try to run command netstat -nltp. It shows active addresses and ports. Your nginx process should be run at 0.0.0.0:8000. 0.0.0.0 means the nginx process is available from anywhere.
If your nginx process is ran by any specific ip address, you should access it by that ip address, e.g http://192.168.4.2:8000.
I'm using a manual proxy configuration on Firefox to use a SSH tunnel and everything works fine. However I try to understand how does it works. From my understanding Firefox is just transferring every request to the specified port but I'm not quite sure of what does it means. Also what happen when I don't use a proxy? I guess Firefox is using an other port or something? Basically I'm trying to understand how a web browser connects to internet.
I am new to Squid proxy, i was able to configure squid in my windows 7 and work as proxy server to talk to outside world. Now i wanted to try to use squid as cascading proxy. and use fiddler to talk to out side world. Have anyone tried this before? Any help will be very useful.
Found the solution we just need to change "cache_peer 127.0.0.1 parent 8888 0 proxy-only default" to what ever port and ip we want to forward to. and i worked like a charm
We're having a weird problem at work and I'm hoping someone here can give me some ideas on how to troubleshoot it.
The problem is that I cannot make websocket connections from my Kubuntu 13.10 workstation. I've tried from both Chrome and Firefox. I'm behind a proxy and first I thought that must be the reason. However, I got some coworkers to try to connect to the same websocket echo demo and all of them were able to, except one. He was the only one running Ubuntu (same as me), the others were on Mac, Windows and even one on RedHat! Theirs all worked fine.
Ok, so now for the really weird part. I created and ran a virtual machine on my workstation (the one that couldn't connect). The VM is a Lubuntu 13.10 and what do you know, the darn thing establishes a websocket connection just fine!
So any ideas on how to troubleshoot this or even some suggestions for solutions would be very much appreciated.
Ugh... well that one was dumb.
So it turns out that in Linux you can check a checkbox in your Network Proxy settings (the system settings) that will use the same proxy for all protocols.
Yeah... don't do that!
Unless, that is, your proxy server supports SOCKS as well as HTTP/HTTPS/FTP (highly unlikely).
It turns out that if you check that checkbox, your proxy server will be registered as a SOCKS proxy and for some reason, websocket connections in both Chrome and Firefox will want to use that. So your HTTP proxy will end up getting a bunch of weird SOCKS handshakes that it doesn't understand and any websocket connection will fail.
This was tested on both Ubuntu and Kubuntu and the "problem" exists on both.
TL;DR; Don't check the "Use this proxy server for all protocols" checkbox unless your proxy server supports the SOCKS protocol. Instead, manually fill in the same server for the different protocols (http, https and ftp) but leave the socks protocol empty (or point to an actual socks proxy server).
This issue is occurring in a C#, .NET 4.0 environment. I tried using Fiddler but it doesn't show up. After searching around, the suggested solution was to change the address of the request from localhost to the machine-name.
This worked on my local machine: after changing the call from localhost to my-machine, fiddler picked it up. The real issue is on a client's staging environment with production code. I can not modify the code there to take this change.
Note, as far as I know, on the client site it should be making the request out to the host name and not localhost anyways.
Also, on my local machine I actually hit localhost in my browser, and it seems to pick those up fine. Just not the request built in code. Why is that?
Thanks!
It sounds like you're saying: "This works fine on the client's PC but not on my dev PC when using Localhost." Is that correct?
In IE9, I changed WinINET to enable Fiddler to capture loopback traffic from the browser. Sadly, the .NET Framework hasn't yet adopted support for the <-loopback> token, which means that traffic sent to 127.0.0.1 or localhost bypasses the proxy.