1. It’s interesting that it’s only curl that’s giving trouble, and only with Guzzle. I’m not convinced this is a Valet issue. You could maybe enable Guzzle’s debug mode, to get more information back: http://docs.guzzlephp.org/en/latest/request-options.html#debug

You could also install an alternate Client to override the default of using CURL: http://docs.guzzlephp.org/en/latest/faq.html#does-guzzle-require-curl

1. I wouldn’t have expected a simple yarn update to do anything that’s interfering, unless it’s gone and installed some package that set some new ENV vars that CURL uses, or something that provides DNS services and now is clashing with dnsmasq or osx core. And if it does then that raises other concerns, beyond the scope of Valet. But, one way to rule it out is to delete everything yarn installed, and then remove the node_modules dir, and reboot. And if it’s from “global” tools that yarn installed, clean those up too. Maybe not “ideal”, but useful as a troubleshooting step nonetheless.

2. Given that you said other services are able to reach site.test it means dnsmasq “is” running, so the following troubleshooting for dnsmasq is probably pointless, but I’ll leave it here for reference anyway.

DNSMASQ troubleshooting

Top 3 troubleshooting steps I’ve taken with dnsmasq issues:

• use dig to find out what’s happening with lookups
• enable dnsmasq logging to get it to report any startup problems
• inspect OSX config

dig

dig site.test This should come back with something like the following. Note the “A” record pointing to 127.0.0.1, and the SERVER: 127.0.0.1 in the following, and what’s different in yours.

; <<>> DiG 9.10.6 <<>> site.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58405
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;site.test.			IN	A

;; ANSWER SECTION:
site.test.		0	IN	A	127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 01 10:26:39 EST 2019
;; MSG SIZE  rcvd: 54

logging

Enabling logging in dnsmasq: One place to do this is in ~/.config/valet/dnsmasq.conf It should already have 2 lines in it for your configured TLD. Add the following lines, adjusting for your actual username:

# Logging
log-facility=/Users/MY_USERNAME/Downloads/dnsmasq.log
log-queries

Then sudo brew services stop dnsmasq && sudo brew services start dnsmasq && brew services list What’s the output? Does it show dnsmasq running as root? Then look in your ~/Downloads/dnsmasq.log file for any messages, particularly things pointing out problems. (Once you’ve resolved your dnsmasq issues, remove those logging entries, since it’ll just waste disk space.)

OSX networking

• System Preferences -> Network -> Advanced -> DNS For dnsmasq to be the first lookup source, the first DNS listing should be 127.0.0.1

I have had this problem several time after doing an update with brew. And I’ve forgotten the solution that works for me several times 😃

As this was one of the first things I hit with google I’m going to post why this occurs for me here.

I got the solution from here https://stackoverflow.com/questions/54688451/curl-laravel-valet-dnsmasq-not-working

Quick way to check if this is your problem is to do: curl --version and php --ri curl

The versions should match. If they don’t it’s probably because brew has installed curl-openssl. This can be removed by doing: brew uninstall curl-openssl --ignore-dependencies

Maybe there’s a way to configure the installed curl-openssl properly - I’ve not investigated this yet.

Thanks @drbyte for the those clear instructions. I did follow all the things you listed.

Adding 127.0.0.1 to System Preferences -> Network -> Advanced -> DNS solves the issue. It was blank at first (actually grayed out) So I just add it as first lookup source.

Thanks!!

Thank you! I’ve been using .localhost for my local valet development, and haven’t experienced a single issue until this passed month where I’ve been using Guzzle in one local app to query another local app/api (both .localhost). I could manually type/visit in both apps and both would load within milliseconds, but took 2-4 minutes with Guzzle, and occasionally would cURL error 6: could not resolve site.localhost`.

I also use a PiHole, so I put it down to something to do with the local resolution, until I found this and added 127.0.0.1 to my DNS.

My DNS entries are in the following order:

127.0.0.1
192.168.1.106 (piHole)
8.8.8.8

Guzzle/cURL are now both instantaneous!

My solution:

sudo vi /etc/hosts

...
add to the buttom:

127.0.0.1 example.test

Just wanted to chime in and say that

brew uninstall curl-openssl --ignore-dependencies

worked for me.

Adding 127.0.0.1 to the DNS server list screwed up my internet (some hosts wouldn’t resolve properly), so I removed it again.

Note: you might need to add back a “real” DNS resource.

You can do that either in the System Prefs DNS pane, or add the following to your dnsmasq.conf file (you don’t need all of them, pick one or two to uncomment):

# fallback DNS servers for regular resolution
#Cloudflare
server=1.1.1.1
server=1.0.0.1
#openDNS
server=208.67.220.222
server=208.67.220.220
#google dns
#server=8.8.8.8
#server=4.4.4.4
#familyshield:
#server=208.67.222.123
#server=208.67.220.123

At first there was 192.168.1.1 in my system preference network DNS added 127.0.0.1 and it solved my problem. thanks @drbyte

But i could not access other networks after that. after that i added 192.168.1.1 below 127.0.0.1 .

Now my guzzle http and browser network both working .

@ahmadabdallah you could add manually the domain to your hosts file it’s not a fix but it will just work fine

You have to keep your same DNS servers as before, just adding 127.0.0.1 removed other defaults. You need to manually add them back but keep 127.0.0.1 at the top.

Yes and no. An even better way is to tell Dnsmasq what you preferred DNS servers are. This is easily done by creating a new config file. Example: to use Cloudflare’s 1.1.1.1 create:

~/.config/valet/dnsmasq.d/dns-cloudflare1111.conf contains:

# fallback servers to use if we can't resolve using our own rules
# these are Cloudflare's public dns
server=1.1.1.1
server=1.0.0.1

Add/remove *.conf files in the ~/.config/valet/dnsmasq.d/ directory to control your Dnsmasq configuration.

**This works since Valet 2.6.0

In addition to DrByte’s reply above, make sure 127.0.0.1 is the first entry in your dns list.

So I have tried everything in this issue thread. The only thing that has worked for me is putting 127.0.0.1 in my DNS entries AT THE TOP

I figured out this mattered after running dig dev-site.test and I got

SERVER: 8.8.8.8#53(8.8.8.8)

Then I moved the localhost(127.0.0.1) address to the top of my DNS entries and that resolved everything for me.

dig dev-site.test now results in:

SERVER: 127.0.0.1#53(127.0.0.1)

Make sure you have this at the top!!! The order matters! At least it did for me…

Hello, I just wanted to add some additional info as I ran into this as well.

I was seeing very slow requests between my Laravel applications with Curl via Guzzle. For some reason file_get_contents worked correctly but curl did not. In my case the Guzzle requests were actually finishing eventually, they just took ~25 seconds.

After turning on verbose logging (CURLOPT_VERBOSE) I saw the following:

* Could not resolve: slow-valet.test (Domain name not found)
* Expire in 300000 ms for 1 (transfer 0x7ff5f4008c00)
* Closing connection 0

I verified the error occurred with both PHP 7.1 and 7.3; changing the version of PHP didn’t make a difference for me.

Adding 127.0.0.1 to the DNS servers as explained above fixed my issue.