Can't seem to do a CURL request to my own server about valet-windows HOT 22 OPEN

@desthercz Only if there is an alternative to Acrylic DNS that works with cURL.

from valet-windows.

Idk if this will also work for you, as I am using the native (mac) valet, but..

Try adding 127.0.0.1 in dns. Make it the first in the list (mac/linux) or maybe primay dns? (windows).

If it still doesnt work. Try out each of these:

1. Restart your wifi/ethernet connection (not the router! just in settings)
2. Restart/Reinstall valet
3. Restart PC

This is pretty much all what I did in sequence to get it working. I was also having similar issue even with native valet after fresh install.

from valet-windows.

This is a problem with a service this package uses, Acrylic DNS that intercepts domains like .test and points to the associated project folder.
But with cURL, the request is made at a lower level and it's not intercepted by the dns proxy.

from valet-windows.

Unfortunately this problem is still not solved, but I've found a workaround that works (at least for my use case). My API project lives on api.example.test, but on my local environment I don't really need that URL to be that exact URL. If you switch from valet to artisan serve (php artisan serve) in the API project and change the url from api.example.test into your local IP, you can do requests to this project from a valet project.

from valet-windows.

Me to, before I install new windows I can use it and good work, and after that I new install it i can't use it.

from valet-windows.

https://drive.google.com/file/d/1gVmTBSo9sdhAGrEdOHcFL59uDpO_CVWj/view?usp=sharing

this after, I config network IP and I run it.

from valet-windows.

Same here. If it helps, here's a readout of the nginx error log
2018/02/02 03:12:36 [error] 2572#10324: *24 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while reading response header from upstream, client: 127.0.0.1, server: phoenix.test, request: "POST /login HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "phoenix.test", referrer: "https://phoenix.test/login"

2018/02/02 03:12:37 [error] 2572#10324: *32 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while reading response header from upstream, client: 127.0.0.1, server: vulcan.test, request: "GET /oauth/token HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "vulcan.test"

PHP 7.1, both sites secured with HTTPS and port 9001 is used by php-cgi, changing to 9000 as suggested in #61 did nothing

from valet-windows.

Has anybody found a solution to this? I'm having the exact same issue as @terrabythia using 2 different projects locally and trying to connect via curl. All of the conditions presented are present in my setup: curl is installed, runs in cli, times out when connecting locally, connect from mydomain.dev to api.otherdomain.dev. I get the same error response in my logs as @LukasJK.

I've also tried changing the ports as in #61, but it did nothing.

Anybody figure this out? Any update @cretueusebiu?

Also, it doesn't matter if I'm using an http or https connection it gives the same errors consistently.

from valet-windows.

@spanglishone You should not be using .dev domains anymore. See this. Use valet domain test to change it to .test.

As for cURL, try adding the domain manually in your hosts file.

from valet-windows.

@cretueusebiu thanks for the response. Yes, I'm aware of the tld issue with .dev. I was using it as an example, but I'm actually not using .dev. I should have been more explicit because I'm using my initials which don't correlate to any tld.

But to rule it out, I went ahead and switched to .test as you suggested. I still get the 504 gateway issue and timeout.

I then edited my windows hosts file and saved the domains

127.0.0.1 api.mydomain.test
127.0.0.1 otherdomain.test

I then ran:
valet stop
followed by
valet start
to rule out valet restart being an issue.

I get the same errors. Any other ideas? Need any additional info?

I really appreciate any help.

Thanks

from valet-windows.

@cretueusebiu makes sense. I just don't know what to do about that because I need to use cURL as I would on a server. Anyway, thanks for the response. Let me know if I can offer any additional info.

from valet-windows.

@spanglishone You can always try using valet share command. This creates a tunnel to the project which should make the cURL commands work without problems.

from valet-windows.

@spanglishone You can always try using valet share command. This creates a tunnel to the project which should make the cURL commands work without problems.

Not working for me :-(

Unfortunately this problem is still not solved, but I've found a workaround that works (at least for my use case). My API project lives on api.example.test, but on my local environment I don't really need that URL to be that exact URL. If you switch from valet to artisan serve (php artisan serve) in the API project and change the url from api.example.test into your local IP, you can do requests to this project from a valet project.

Thanks for this workaround, it works nicely.

@cretueusebiu do you have any solution for this or is it unfixable?

from valet-windows.

Is there a fix for this yet? I'm trying to use Win 10 now for development and this is really holding me back. I have internal curl calls from my apps to a service called auth.test and they all fail which is my oAuth2 server. Only way I've been able to get it to work is doing the artisan serve trick but that is pretty tacky.

from valet-windows.

@seivad How is it holding you back? I also use "php artisan serve" trick and it works pretty fine. Only pitfall i can see is when you need to access multiple local APIs, but that does not seems to be your case.
The only real "fix" to this issue is using Valet on either Linux or MacOs sadly. I put some hours to researching alternatives to Acryllic DNS proxy back in November but didnt found anything.

from valet-windows.

I haven't found any solution to this.

from valet-windows.

This issue is seriously impacting local WordPress development in Windows 10 with the new Gutenberg editor that does everything via curl. Saving changes in posts is a lottery, sometimes it works, mostly it simply doesn't.
The new Site Health feature in WP reports curl 28 error.

from valet-windows.

@bonovski Yea but it is not a bug which can be fixed. Only option is to use something else than Acryllic DNS proxy and so far no one found an alternative.

In your case you have to use something else like Xampp. Or switch to Mac/Linux, where this issue is not present.

from valet-windows.

Having the same issue with nginx 1.19
2 mezzio apps configured on the same Nginx(windows)
making a request from the browser works like a charm, making a PHP curl request from one to another fails as 502 Bad Gateway and although the request gets logged by Nginx, it never reaches the app

from valet-windows.

There is no point of reporting another case of this bug. It is confirmed and atm this cannot be fixed, there are only few workarounds mentioned above. Switch to Linux and voila, problem fixed :P

from valet-windows.

I'm on Linux (Ubuntu 20), same issue with cURL. Unable to resolve latest TLDs like .dev, .app, et. al.

from valet-windows.

Has anyone found the solution of this yet?

from valet-windows.