Valet: This site can't be reached / ERR_CONNECTION_REFUSED

Created on 4 Nov 2020 · 85Comments · Source: laravel/valet

Two days ago, seemingly out of nowhere, my Valet sites suddenly had all stopped working. If I try to load any of them in a browser I just get:

(Chrome)
This site can’t be reached
cufm.test’s server IP address could not be found.

(Firefox)
We can’t connect to the server at cufm.test.

Over the past two days I've tried absolutely everything I could find in previous similar issues, but nothing seemed to fix it on my machine. I ultimately even wiped the entire machine and restored a Time Machine backup from last week (when things were working). But even that somehow didn't fix the issue.

Running valet uninstall --force fails with a The process has been signaled with signal "9". error, but trying any of the fixes mentioned in #876 don't fix that issue for me. So I've attempted a manual uninstall and reinstall with:

valet unsecure --all
rm -rf ~/.config/valet
composer global remove laravel/valet
brew uninstall --force php nginx dnsmasq
sudo rm -rf /usr/local/Cellar/php/7.4.12

brew update
brew upgrade
brew cleanup    (no issues)
brew doctor    (no issues)

brew install php
composer global require laravel/valet
valet install

No luck, so I decided to remove Homebrew and Composer completely and just start over from scratch:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)"
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
brew upgrade
brew install php

rm /usr/local/bin/composer
rm -rf ~/.composer
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'c31c1e292ad7be5f49291169c0ac8f683499edddcfd4e42232982d0fd193004208a58ff6f353fde0012d35fdd72bc394') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar /usr/local/bin/composer

composer global require laravel/valet
valet install
cd ~/Sites
valet park

Still nothing, same issue as before. When checking the logs, ~/.config/valet/Log/nginx-error.log is empty and /usr/local/var/log/php-fpm.log shows:

NOTICE: fpm is running, pid 72876
NOTICE: ready to handle connections

Running valet uninstall --force still fails with a The process has been signaled with signal "9". error.

I'm out of ideas, but really hoping someone can point me in the right direction.

Source

mikepostma

All 85 comments

This site can’t be reached
cufm.test’s server IP address could not be found.

This suggests to me that you have a networking issue.

Normally dnsmasq would be providing the IP resolution. But if the browser is saying the IP address could not be found then it suggests your Mac is unable to lookup the IP for the domain ... which suggests dnsmasq is not operating or is not being consulted for DNS queries.

Would you run valet diagnose and paste the output of that in a separate reply?

drbyte on 4 Nov 2020

After that, does running valet tld test solve the problem? This is valet's default, but if part of the config for it has been damaged perhaps this might reset it.

drbyte on 4 Nov 2020

Among other things, I'd be exploring:

brew services list - what's it saying about dnsmasq? Should be running as root, with no errors
what are your system's resolvers set to? In System Preferences, Network, Wifi, DNS, what are the DNS Servers? If 127.0.0.1 is not there or not first in the list, do you have an intentional reason?
ping foo.test - what's the output
You said this all started "2 days ago". What changed on your mac 2 days ago? Reboot? Software upgrades? Software installs? New apps? Removed apps?
does /private/etc/resolver/test exist? what's in it? It should say nameserver 127.0.0.1 inside.

You could enable dnsmasq logging by creating /Users/mike/.config/dnsmasq.d/config-logging-on.conf containing:

# specify a log file location
log-facility=/Users/mike/.config/valet/Logs/dnsmasq.log
## the following line enables logging
log-queries

(delete the file or rename it without a .conf extension when you don't need logging anymore; the file gets large fast)

You could delete dnsmasq and let Valet reinstall it:

sudo brew services stop dnsmasq
brew remove dnsmasq
rm -rf /usr/local/etc/dnsmasq.conf /usr/local/etc/dnsmasq.d ~/config/valet/dnsmasq.d
valet install
valet tld test

Advanced tip taken from a Genius Bar employee when I had a very odd networking issue (nothing would connect anywhere) that absolutely all other tactics couldn't resolve: Go to System Preferences, Network, and in the Locations dropdown, note which one is selected currently, choose Edit, create a new one, and delete the prior one. Reboot. Sometimes this magically fixes the world. I wouldn't do it unless you need to, but since you said you have a current reliable backup it feels safe to try.

drbyte on 4 Nov 2020

Thanks for all the great suggestions.

Running valet tld test did not fix the issue, but I noticed that the error message in Chrome has shifted from:

This site can’t be reached
cufm.test’s server IP address could not be found.
ERR_NAME_NOT_RESOLVED

This site can’t be reached
cufm.test refused to connect.
ERR_CONNECTION_REFUSED

Mind you, I didn't recheck just before running valet tld test, so I'm not a 100% sure whether that command specifically caused the error message to change or if it was something else done before then.

brew services list outputs:

Name    Status  User Plist
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
nginx   started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php     started root /Library/LaunchDaemons/homebrew.mxcl.php.plist

The DNS Servers in System Preferences are set to:

127.0.0.1
1.1.1.1
1.0.0.1

Pinging any .test domain works fine:

[~]$ ping foo.test
PING foo.test (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.031 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.120 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.121 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.218 ms

I first noticed the issue 2 days ago (Monday). The only thing that would've changed between Friday (when it was working) and then is the installation (and subsequent removal) of ExpressVPN. The uninstall was done using these instructions. Apologies for not mentioning that earlier, although having done a full wipe of the disk and Time Machine restore to 7 days ago should've gotten rid of any traces of it (in theory at least). I also have Private Internet Access as a VPN on this machine, but that's been there for years and has never caused on issue with Valet (either turned on or off).
/private/etc/resolver/test exists and the contents are nameserver 127.0.0.1
dnsmasq logging outputs the following relevant lines:

Nov  4 15:36:42 dnsmasq[10176]: started, version 2.82 cachesize 150
Nov  4 15:36:42 dnsmasq[10176]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth no-DNSSEC loop-detect no-inotify dumpfile
Nov  4 15:36:42 dnsmasq[10176]: setting --bind-interfaces option because of OS limitations
Nov  4 15:36:42 dnsmasq[10176]: reading /etc/resolv.conf
Nov  4 15:36:42 dnsmasq[10176]: ignoring nameserver 127.0.0.1 - local interface
Nov  4 15:36:42 dnsmasq[10176]: using nameserver 1.1.1.1#53
Nov  4 15:36:42 dnsmasq[10176]: using nameserver 1.0.0.1#53
Nov  4 15:36:42 dnsmasq[10176]: read /etc/hosts - 4 addresses
...
Nov  4 15:37:05 dnsmasq[10176]: query[A] cufm.test from 127.0.0.1
Nov  4 15:37:05 dnsmasq[10176]: config cufm.test is 127.0.0.1
Nov  4 15:37:05 dnsmasq[10176]: query[AAAA] cufm.test from 127.0.0.1
Nov  4 15:37:05 dnsmasq[10176]: config cufm.test is NODATA-IPv6

Deleting dnsmasq and letting Valet reinstall it does not seem to make a difference.
I tried the "Locations" hack and was really hoping it would magically make things work, but unfortunately not. It didn't break anything else though, so no need to go back to the full backup.

mikepostma on 4 Nov 2020

Output from valet diagnose:

sw_vers

ProductName: Mac OS X
ProductVersion: 10.15.7
BuildVersion: 19H2

valet --version

Laravel Valet 2.12.0

cat ~/.config/valet/config.json

{
    "tld": "test",
    "paths": [
        "/Users/mpostma/Sites"
    ]
}

cat ~/.composer/composer.json

{
    "repositories": [
        {
             "type": "composer", 
             "url": "https://packagist.org"
        },
        { "packagist": false }
    ],
    "require": {
        "laravel/valet": "^2.12"
    }
}

composer global diagnose

Changed current directory to /Users/mpostma/.composer
Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 2.0.4
PHP version: 7.4.12
PHP binary path: /usr/local/Cellar/php/7.4.12/bin/php
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020
cURL version: 7.73.0 libz 1.2.11 ssl OpenSSL/1.1.1h
zip extension: OK

composer global outdated

Changed current directory to /Users/mpostma/.composer

ls -al /etc/sudoers.d/

total 0
drwxr-xr-x    2 root  wheel    64 23 Aug  2019 .
drwxr-xr-x  121 root  wheel  3872  4 Nov 16:09 ..

brew config

HOMEBREW_VERSION: 2.5.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: 1c822206a05cd7fffe526b8e0fa2f45365be72a5
Last commit: 8 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: cf5f5197a874af0cfdabd51cf56802d04263ca21
Core tap last commit: 45 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.IX4DLM4LUu/org.macosforge.xquartz:0
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit haswell
Clang: 12.0 build 1200
Git: 2.24.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
Java: 1.8.0_92
macOS: 10.15.7-x86_64
CLT: 12.1.0.0.1.1602137645
Xcode: 12.1
XQuartz: 2.7.11 => /opt/X11

brew services list

Name    Status  User Plist
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
nginx   started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php     started root /Library/LaunchDaemons/homebrew.mxcl.php.plist

curl-openssl 7.73.0
dnsmasq 2.82
nginx 1.19.4
[email protected] 1.1.1h
php 7.4.12

brew outdated

php -v

PHP 7.4.12 (cli) (built: Oct 29 2020 18:37:21) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.12, Copyright (c), by Zend Technologies

which -a php

/usr/local/bin/php
/usr/bin/php

php --ini

Configuration File (php.ini) Path: /usr/local/etc/php/7.4
Loaded Configuration File:         /usr/local/etc/php/7.4/php.ini
Scan for additional .ini files in: /usr/local/etc/php/7.4/conf.d
Additional .ini files parsed:      /usr/local/etc/php/7.4/conf.d/ext-opcache.ini,
/usr/local/etc/php/7.4/conf.d/php-memory-limits.ini

nginx -v

nginx version: nginx/1.19.4

curl --version

curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

php --ri curl

curl

cURL support => enabled
cURL Information => 7.73.0
Age => 7
Features
AsynchDNS => Yes
CharConv => No
Debug => No
GSS-Negotiate => No
IDN => No
IPv6 => Yes
krb4 => No
Largefile => Yes
libz => Yes
NTLM => Yes
NTLMWB => Yes
SPNEGO => Yes
SSL => Yes
SSPI => No
TLS-SRP => Yes
HTTP2 => Yes
GSSAPI => Yes
KERBEROS5 => Yes
UNIX_SOCKETS => Yes
PSL => No
HTTPS_PROXY => Yes
MULTI_SSL => No
BROTLI => Yes
Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, mqtt, pop3, pop3s, rtmp, rtsp, scp, sftp, smb, smbs, smtp, smtps, telnet, tftp
Host => x86_64-apple-darwin19.6.0
SSL Version => OpenSSL/1.1.1h
ZLib Version => 1.2.11
libSSH Version => libssh2/1.9.0

Directive => Local Value => Master Value
curl.cainfo => no value => no value

~/.composer/vendor/laravel/valet/bin/ngrok version

ngrok version 2.3.35

ls -al ~/.ngrok2

total 8
drwx------    3 mpostma  staff    96 16 Apr  2018 .
drwxr-xr-x+ 114 mpostma  staff  3648  4 Nov 16:24 ..
-rw-------    1 mpostma  staff    55 16 Apr  2018 ngrok.yml

brew info nginx

nginx: stable 1.19.4 (bottled), HEAD
HTTP(S) server and reverse proxy, and IMAP/POP3 proxy server
https://nginx.org/
/usr/local/Cellar/nginx/1.19.4 (25 files, 2.2MB) *
  Poured from bottle on 2020-11-04 at 16:19:53
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/nginx.rb
License: BSD-2-Clause
==> Dependencies
Required: [email protected], pcre
==> Options
--HEAD
  Install HEAD version
==> Caveats
Docroot is: /usr/local/var/www

The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.

nginx will load all files in /usr/local/etc/nginx/servers/.

To have launchd start nginx now and restart at login:
  brew services start nginx
Or, if you don't want/need a background service you can just run:
  nginx
==> Analytics
install: 48,421 (30 days), 113,783 (90 days), 428,697 (365 days)
install-on-request: 47,590 (30 days), 111,695 (90 days), 416,785 (365 days)
build-error: 0 (30 days)

brew info php

php: stable 7.4.12 (bottled), HEAD
General-purpose scripting language
https://www.php.net/
/usr/local/Cellar/php/7.4.12 (497 files, 72.3MB) *
  Poured from bottle on 2020-11-04 at 16:05:28
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/php.rb
License: PHP-3.01
==> Dependencies
Build: httpd, pkg-config
Required: apr, apr-util, argon2, aspell, autoconf, curl-openssl, freetds, gd, gettext, glib, gmp, icu4c, krb5, libffi, libpq, libsodium, libzip, oniguruma, openldap, [email protected], pcre2, sqlite, tidy-html5, unixodbc
==> Options
--HEAD
  Install HEAD version
==> Caveats
To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php7_module /usr/local/opt/php/lib/httpd/modules/libphp7.so

    
        SetHandler application/x-httpd-php
    

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

The php.ini and php-fpm.ini file can be found in:
    /usr/local/etc/php/7.4/

To have launchd start php now and restart at login:
  brew services start php
Or, if you don't want/need a background service you can just run:
  php-fpm
==> Analytics
install: 56,220 (30 days), 159,335 (90 days), 579,152 (365 days)
install-on-request: 55,174 (30 days), 155,870 (90 days), 550,857 (365 days)
build-error: 0 (30 days)

brew info openssl

[email protected]: stable 1.1.1h (bottled) [keg-only]
Cryptography and SSL/TLS Toolkit
https://openssl.org/
/usr/local/Cellar/[email protected]/1.1.1h (8,067 files, 18.5MB)
  Poured from bottle on 2020-11-04 at 10:20:03
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/[email protected]
License: OpenSSL
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/[email protected]/certs

and run
  /usr/local/opt/[email protected]/bin/c_rehash

[email protected] is keg-only, which means it was not symlinked into /usr/local,
because macOS provides LibreSSL.

If you need to have [email protected] first in your PATH run:
  echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> ~/.zshrc

For compilers to find [email protected] you may need to set:
  export LDFLAGS="-L/usr/local/opt/[email protected]/lib"
  export CPPFLAGS="-I/usr/local/opt/[email protected]/include"

==> Analytics
install: 835,013 (30 days), 1,906,254 (90 days), 7,237,126 (365 days)
install-on-request: 136,062 (30 days), 257,990 (90 days), 1,007,070 (365 days)
build-error: 0 (30 days)

openssl version -a

LibreSSL 2.8.3
built on: date not available
platform: information not available
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: information not available
OPENSSLDIR: "/private/etc/ssl"

openssl ciphers

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:GOST2012256-GOST89-GOST89:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:GOST2001-GOST89-GOST89:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA256:CAMELLIA128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA

sudo nginx -t

nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

which -a php-fpm

/usr/local/sbin/php-fpm
/usr/sbin/php-fpm

/usr/local/opt/php/sbin/php-fpm -v

PHP 7.4.12 (fpm-fcgi) (built: Oct 29 2020 18:37:31)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.12, Copyright (c), by Zend Technologies

sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.4/php-fpm.conf --test

[04-Nov-2020 16:24:47] NOTICE: configuration file /usr/local/etc/php/7.4/php-fpm.conf test is successful

ls -al ~/Library/LaunchAgents | grep homebrew

ls -al /Library/LaunchAgents | grep homebrew

ls -al /Library/LaunchDaemons | grep homebrew

-rw-r--r--   1 root  admin   657  4 Nov 16:20 homebrew.mxcl.dnsmasq.plist
-rw-r--r--   1 root  admin   571  4 Nov 16:20 homebrew.mxcl.nginx.plist
-rw-r--r--   1 root  admin   628  4 Nov 16:20 homebrew.mxcl.php.plist
-rw-r--r--   1 root  admin   636  3 Nov 22:14 [email protected]

mikepostma on 4 Nov 2020

ERR_CONNECTION_REFUSED generally suggests nginx isn't responding.
It can also occasionally mean nginx couldn't proxy to the intended destination service ... in this case php-fpm.

But, given that both of those services show as running normally without error, diagnosing is a little more complicated.

drbyte on 4 Nov 2020

I get SEC_ERROR_UNKNOWN_ISSUER when trying to access the expressvpn site.

That said, VPN clients do definitely tinker with networking configurations. I'm not sure what exactly expressVPN "touches" though.

drbyte on 4 Nov 2020

Yeah I don't know what/if ExpressVPN touches anything, which is why I ultimately decided to restore from a the backup.

The most frustrating part is that I can't seem to pin down where the problem is (dnsmasq, nginx, php), which makes it pretty hard to start looking for solutions. Is there a way to turn on a general/access log file for nginx, similar to what we did for dnsmasq, so we can see if these requests even hit nginx?

mikepostma on 4 Nov 2020

ERR_CONNECTION_REFUSED will fire if nginx is not running on the IP address that was resolved from the domain name entered.

If nginx connects but PHP-FPM isn't running then usually it gives 502 Bad Gateway.

If nginx and php connect but Valet can't find a site in the registered "parked" paths, it defaults to returning 404 - Not Found

drbyte on 4 Nov 2020

By default Valet tells Nginx to store error logs at /Users/USER/.config/valet/Log/nginx-error.log

(This is set in /usr/local/etc/nginx/valet/valet.conf)

drbyte on 4 Nov 2020

Is there any chance you've got a service running on port 80 that's causing nginx not to be able to bind to it?

drbyte on 4 Nov 2020

There's nothing in the nginx-error.log file.

Prior to starting valet there's no output for sudo lsof -i tcp:80

After valet start it gives me:

COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
nginx   2933 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2938 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2939 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2940 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2941 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2942 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2943 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2944 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)
nginx   2945 root    6u  IPv4 0x8b74f38ccd235059      0t0  TCP localhost:http (LISTEN)

After running valet stop the output of that command is empty again.

mikepostma on 4 Nov 2020

Random thought seeing that output, could this be a localhost vs 127.0.0.1 issue?

mikepostma on 4 Nov 2020

worth checking

try this to compare: lsof -Pn -i4 | grep :80

drbyte on 4 Nov 2020

homed      679 mpostma   21u  IPv4 0x8b74f38cc6ca78d9      0t0  TCP 192.168.86.217:49185->192.168.86.231:8080 (ESTABLISHED)
SoundTouc 1159 mpostma   12u  IPv4 0x8b74f38cccefe679      0t0  TCP *:8085 (LISTEN)

mikepostma on 4 Nov 2020

for your sudo lsof -i tcp:80 I get:

COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
nginx   73382  root    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73391 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73392 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73393 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73394 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73395 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73396 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73397 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)
nginx   73398 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP localhost:http (LISTEN)

Note the root for the first, and my username for all the rest.
Granted, a few minutes ago I ran sudo brew services stop nginx and sudo brew services start nginx so maybe the child processes started differently than they would on boot.

drbyte on 4 Nov 2020

lsof -Pn -i4 | grep :80
gives me:

nginx     73391 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73392 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73393 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73394 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73395 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73396 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73397 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     73398 chris    9u  IPv4 0xb58c2774df858807      0t0  TCP 127.0.0.1:80 (LISTEN)

Noting here the 127.0.0.1 vs localhost observation you mentioned. So, same in that regard. But username vs root still.

drbyte on 4 Nov 2020

Ok, I just tried stopping and restarting via brew like you did and that doesn't change anything. Everything is still root on sudo lsof -i tcp:80 and lsof -Pn -i4 | grep :80 doesn't list any nginx processes for me. I'm not super familiar with the lsof command so a bit out of my depth here. What is the second variation showing and could you offer any guesses as to why that's empty for me?

mikepostma on 4 Nov 2020

If I run your second command but with sudo in front of it, I get:

nginx     6093           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6100           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6101           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6102           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6103           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6104           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6105           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6106           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)
nginx     6107           root    6u  IPv4 0x8b74f38ccac052b9      0t0  TCP 127.0.0.1:80 (LISTEN)

mikepostma on 4 Nov 2020

There's nothing in the nginx-error.log file.

I guess that's normal unless actual errors occur.

Maybe we can try turning on debug mode with it:
/usr/local/etc/nginx/valet/valet.conf

    access_log off;
-    error_log "/Users/USERNAME/.config/valet/Log/nginx-error.log";
+    error_log "/Users/USERNAME/.config/valet/Log/nginx-error.log" debug;

Then valet stop/start again.

Then try to visit http://foo.test and see what shows up in your ~/.config/valet/Log/nginx-error.log

drbyte on 4 Nov 2020

Ok, will try that, also I case this might be relevant, the contents of /usr/local/etc/nginx/nginx.conf are:

user "mpostma" staff;
worker_processes auto;

events {
    worker_connections  1024;
}

http {
    include mime.types;
    default_type  application/octet-stream;

    sendfile on;
    keepalive_timeout  65;
    types_hash_max_size 2048;

    client_max_body_size 512M;

    server_names_hash_bucket_size 128;

    ssi on;

    gzip  on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_vary on;
    gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/rss+xml
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/svg+xml
    image/x-icon
    text/css
    text/plain
    text/x-component;

    include "/Users/mpostma/.config/valet/Nginx/*";
    include servers/*;
    include valet/valet.conf;
}

mikepostma on 4 Nov 2020

Ok, will try that, also I case this might be relevant, the contents of /usr/local/etc/nginx/nginx.conf are:

That looks normal. It's built from the stub at ~/.composer/vendor/laravel/valet/cli/stubs/nginx.conf

drbyte on 4 Nov 2020

So valet start generates the following output in the error log with debug on:

2020/11/04 18:24:25 [debug] 9784#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9783#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9785#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9786#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9787#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9788#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9789#0: kevent set event: 7: ft:-1 fl:0005
2020/11/04 18:24:25 [debug] 9790#0: kevent set event: 7: ft:-1 fl:0005

Visiting a .test domain doesn't log anything.

mikepostma on 4 Nov 2020

I get the same basic log content upon startup.

But when I hit a .test domain that it responds to I get a thousand debug lines in the log.

So ... it's as though the request isn't actually hitting nginx ... like still maybe DNS isn't pointing to localhost, or nginx is being intercepted

drbyte on 4 Nov 2020

What happens when you try http://127.0.0.1 in various browsers?

drbyte on 4 Nov 2020

Yeah, was just to mention that mine is still showing "refused to connect" in the browser so it may never actually get to nginx.

mikepostma on 4 Nov 2020

http://127.0.0.1 is the same as any .test domain.

mikepostma on 4 Nov 2020

http://127.0.0.1 is the same as any .test domain.

Okay, I think we've at least narrowed it fairly certainly to nginx not getting the traffic, so it doesn't know to even respond.

drbyte on 4 Nov 2020

Yeah, so if I go valet tld nope and hit any .test domain the error in Chrome is ERR_NAME_NOT_RESOLVED. If I switch back with valet tld test it goes back to ERR_CONNECTION_REFUSED.

mikepostma on 4 Nov 2020

Really appreciate the realtime support by the way!

mikepostma on 4 Nov 2020

Yeah, so if I go valet tld nope and hit any .test domain the error in Chrome is ERR_NAME_NOT_RESOLVED. If I switch back with valet tld test it goes back to ERR_CONNECTION_REFUSED.

Ya, that was a good test.

drbyte on 4 Nov 2020

Really appreciate the realtime support by the way!

Glad to help. I'm scared I'm running out of ideas though! 😊

drbyte on 4 Nov 2020

FWIW the "signal '9'" thing during uninstall is most likely caused by a chicken/egg situation ... '9' is a 'kill' signal, and it's possible that it can't kill the thing that's calling the kill request.
Either way, not relevant to this immediate case.
So ... to help minimize confusion to future searchers, would you update the title to remove that part? Maybe change to This site can't be reached / ERR_CONNECTION_REFUSED might be most reflective of the issue?

drbyte on 4 Nov 2020

I've not had to dig into why traffic isn't routed to nginx as expected, when the DNS is pointing correctly, and lsof shows it listening on the correct port, and nginx is showing as running.
I'm just making (mildly educated) guesses at this point.

I'm guessing this will give you the same as the browser does, but try command line:
curl -i http://127.0.0.1/nginx_status

drbyte on 4 Nov 2020

That gives me curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

mikepostma on 4 Nov 2020

Okay, that's at least consistent with the browser response.

Now I'm wondering about firewall software that might be interfering.
Do you have any known firewall apps installed?

In System Preferences->Security & Privacy, on the Firewall tab, is it enabled? If yes, does temporarily turning it off as a test make any difference? If yes, in Options what checkboxes are ticked?
(Normally this only affects traffic coming in from external connections, not stuff internal to your Mac, so it may be moot.)

drbyte on 5 Nov 2020

Does this problem persist when your other VPN client is active?

drbyte on 5 Nov 2020

The Firewall is turned off and enabling/disabling the other VPN client doesn't seem to make difference. I do have Little Snitch on this machine, which could be used to block requests, but disabled it completely at some point to make sure that wasn't it.

mikepostma on 5 Nov 2020

I use Little Snitch all the time, without issue. Granted, I haven't tried creating a rogue rule to specifically block something ... let alone look for a rogue rule that needs deleting for a case like this.

drbyte on 5 Nov 2020

What's the content of \etc\resolv.conf?
Where's it linked to? ls -aln /etc/resolv.conf

You may have already seen this post about ExpressVPN:
https://github.com/laravel/valet/issues/527#issuecomment-427967761

drbyte on 5 Nov 2020

So I just turned it on though to see what IP addresses the dnsmasq services is trying to access and only 1.1.1.1 and 1.0.0.1 show up (not 127.0.0.1). Not a 100% sure if it would when things are working as they should, but I suspect it would. That might be something you can check.

mikepostma on 5 Nov 2020

/etc/resolv.conf:

#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
domain lan
nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 1.0.0.1

mikepostma on 5 Nov 2020

👍1

Links to lrwxr-xr-x 1 0 0 22 21 Nov 2019 /etc/resolv.conf -> ../var/run/resolv.conf

mikepostma on 5 Nov 2020

👍1

So I just turned it on though to see what IP addresses the dnsmasq services is trying to access and only 1.1.1.1 and 1.0.0.1 show up (not 127.0.0.1). Not a 100% sure if it would when things are working as they should, but I suspect it would. That might be something you can check.

Seems normal.

drbyte on 5 Nov 2020

With regard to #527 above, yes I came across that early on when I still had ExpressVPN installed. I tried it and it didn't seem to make a difference. Since restoring the backup didn't resolve anything, I could try reinstalling ExpressVPN and toggling some checkboxes again / turning the service on and off to see if makes any difference at all.

mikepostma on 5 Nov 2020

With regard to #527 above, yes I came across that early on when I still had ExpressVPN installed. I tried it and it didn't seem to make a difference. Since restoring the backup didn't resolve anything, I could try reinstalling ExpressVPN and toggling some checkboxes again / turning the service on and off to see if makes any difference at all.

Ya, I was thinking that might be a worthwhile step.

Might even be worth doing something similar with the other VPN too, even if only to have it "reset" some things that it knows need to be in place. I wouldn't want to break it on you though, so you can decide whether it'll be fine since you have a backup.

drbyte on 5 Nov 2020

Double-checking: earlier you said you had deleted the ~/.config/valet directory as part of a fresh Valet install.
Did you restore any files to that directory? Or is it still "clean"?

Particularly, the ~/.config/valet/Nginx folder contains site configurations (usually those are generated by Valet, and only when you 'secure' a site).
Sometimes people also add custom configuration rules for Nginx. I just want to be sure there's nothing in there that's interfering with nginx. Granted, if it were then I'd expect something in the debug log or even an error in the configuration test.

drbyte on 5 Nov 2020

Yeah, that folder is still clean. I've done several complete uninstalls and reinstalls since then too. Always trying to make sure I'm testing individual fixes on as clean of an install as possible.

mikepostma on 5 Nov 2020

Given nginx is only listening on IPv4 by default, could try IPv6:
/usr/local/etc/nginx/valet/valet.conf

server {
    listen 127.0.0.1:80 default_server;
+    listen [::1]:80 default_server;
    root /;

and valet stop/start
then curl -i http://\[::1\]/

drbyte on 5 Nov 2020

Idea: Just trying here to explore another port in case something's blocking the usual 80/443 ports:

Create a ~/Sites/foo directory, valet link it and valet secure it. This will create certs and a fresh Nginx config for that domain. Of course then it should respond on ports 80 and 443. But also port 60 (we use that for ngrok tunneling) so you could test curl -i http://foo.test:60 to see if the response is any different (eg: not "connection refused").

drbyte on 5 Nov 2020

Yup, port 60 responds just fine:

HTTP/1.1 200 OK
Server: nginx/1.19.4
Date: Thu, 05 Nov 2020 01:10:39 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.4.12
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive

mikepostma on 5 Nov 2020

😕1

Idea: Could try installing apache to listen on port 80 and see if somehow it gets through.

# see if Apache is installed ("httpd") -- this should return a version number if installed, or blank if not
brew list --versions | grep httpd

# stop nginx so it's not listening on the same ports
sudo services stop nginx

# edit the apache config and change "Listen 8080" to "Listen 80"
sed -i '' 's/Listen 8080$/Listen 80/' /usr/local/etc/httpd/httpd.conf

# start Apache
sudo brew services start httpd

Try visiting the site. By default it'll likely say "Welcome to nginx!" (ya, the irony is palpable)

(To install Apache if needed: brew install httpd)

drbyte on 5 Nov 2020

Yup, port 60 responds just fine:

Definitely curious what's blocking port 80 then.

Did the nginx log show much debug info about that port 60 hit?

How about port 443? blocked?

drbyte on 5 Nov 2020

Port 443 is also blocked, I'll check the nginx log in a second. Just doing that Apache test.

mikepostma on 5 Nov 2020

Back to lsof again.
-iTCP:80 = "check the [i]nterface using TCP on port 80"
-sTCP:LISTEN = only report on those in a [s]tate of LISTEN
-nP = don't resolve the [P]ort [n]ame

sudo lsof -iTCP:80 -sTCP:LISTEN -nP
sudo lsof -iTCP:443 -sTCP:LISTEN -nP
sudo lsof -iTCP:60 -sTCP:LISTEN -nP

Should only display services that are actively running and listening on those ports.
Without sudo will only show non-root services that match the filters

drbyte on 5 Nov 2020

In case there's something about 127.0.0.1 itself in your nginx config, we could try the following, kinda like the ipv6 test:

/usr/local/etc/nginx/valet/valet.conf (this file serves the default sites that are not valet secured)

server {
-    listen 127.0.0.1:80 default_server;
+    listen 80 default_server;
    root /;

and valet stop/start

drbyte on 5 Nov 2020

Ok, before we move on from httpd stuff. I'm getting what I think is pretty wonky behaviour there. Making changes to /usr/local/etc/httpd/httpd.conf doesn't seem to have any effect. Running which httpd returns /usr/sbin/httpd which isn't the brew version, correct? Could it be that that's the culprit?

mikepostma on 5 Nov 2020

You may not have the homebrew Apache installed. That's normally fine (Valet doesn't use apache).
MacOS installs Apache by default ... which is likely the version you're seeing in the sbin dir ... which is also why your .conf file isn't taking effect (cuz it uses a conf in a different default dir).

But ... if that version of apache is actually running then maybe it's conflicting somewhere. Normally it's left turned off.

drbyte on 5 Nov 2020

I didn't have the homebrew Apache installed earlier, but I installed it when you suggested we give Apache a try and I'm starting and stopping it via homebrew. The config seems to be taking effect now all of the sudden, but the which command is still showing the sbin version. Not sure what's happening there.

In any case, with Apache running it's loading http://localhost just fine, but nothing shows at http://127.0.0.1. Although that may be expected given that localhost is defined as the ServerName?

mikepostma on 5 Nov 2020

which by default only resolves the first one found on the PATH

which -a httpd should show all that "could" resolve from the PATH

drbyte on 5 Nov 2020

Ah right on, yeah with the -a flag it shows /usr/local/bin/httpd as well

mikepostma on 5 Nov 2020

I've not been expecting the Apache test to "give" us much.
But if it is indeed now listening on port 80 then trying to start Nginx should fail with "another service is already listening" in its error log. It would be good to get proof of that.

drbyte on 5 Nov 2020

So just to be clear on that last one, you want me to try to start valet while Apache is running?

mikepostma on 5 Nov 2020

Yes

drbyte on 5 Nov 2020

In case there's something about 127.0.0.1 itself in your nginx config, we could try the following, kinda like the ipv6 test:

/usr/local/etc/nginx/valet/valet.conf (this file serves the default sites that are not valet secured)
server {
-    listen 127.0.0.1:80 default_server;
+    listen 80 default_server;
    root /;
and valet stop/start

I currently have this, but it doesn't make a difference in terms of websites loading the browser. Was there a specific test you wanted to do here?

mikepostma on 5 Nov 2020

I currently have this, but it doesn't make a difference in terms of websites loading the browser. Was there a specific test you wanted to do here?

No, just see if the connection-refused message changes or not

EDIT: .... while Nginx is running of course ....

drbyte on 5 Nov 2020

Ok, starting valet/nginx with apache also running doesn't throw any errors

mikepostma on 5 Nov 2020

No, just see if the connection-refused message changes or not

EDIT: .... while Nginx is running of course ....

It doesn't, same message as before.

mikepostma on 5 Nov 2020

Ok, starting valet/nginx with apache also running doesn't throw any errors

Strange. That makes me think your Nginx is a dud.

Let's test something:

sudo nginx -t (to test the config) -- should give 2 lines, saying basically "ok"
Edit /usr/local/etc/nginx/valet/valet.conf again, and change the word "server" on the first line to "foobar".
sudo nginx -t again -- this time it should complain that the syntax is bad. If it doesn't then it's not even looking at the right configs, so can't be listening to anything.

drbyte on 5 Nov 2020

nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

nginx: [emerg] unknown directive "foobar" in /usr/local/etc/nginx/valet/valet.conf:1
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

mikepostma on 5 Nov 2020

👍1

Although that may be expected given that localhost is defined as the ServerName?

No idea.

In any case, with Apache running it's loading http://localhost just fine, but nothing shows at http://127.0.0.1.

What did "just fine" look like?
... and "nothing shows" means ... blank page? .... but also no "error"?

drbyte on 5 Nov 2020

Can you get the Apache thing running again, and test both http://localhost and http://127.0.0.1 using curl -i

I'm curious what the "nothing shows" actually returns. Curl will show some header responses, hopefully.

drbyte on 5 Nov 2020

nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

nginx: [emerg] unknown directive "foobar" in /usr/local/etc/nginx/valet/valet.conf:1
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

Argh. It's doing what it's supposed to. Except for actually serving content.

You can undo that foobar change.

drbyte on 5 Nov 2020

$ curl -i localhost
HTTP/1.1 200 OK
Date: Thu, 05 Nov 2020 02:10:03 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.12
Last-Modified: Thu, 05 Nov 2020 01:10:34 GMT
ETag: "8-5b351c34ed680"
Accept-Ranges: bytes
Content-Length: 8
Content-Type: text/html

Foo Test%                                                                                                                                           

$ curl -i 127.0.0.1
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

To be clear, this is with just Apache running and the following in vhost config:

<VirtualHost _default_:80>
    ServerName localhost
    DocumentRoot "/Users/mpostma/Sites/foo"
</VirtualHost>

mikepostma on 5 Nov 2020

Hmmm

drbyte on 5 Nov 2020

$ curl -i localhost
HTTP/1.1 200 OK
Date: Thu, 05 Nov 2020 02:10:03 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.12
Last-Modified: Thu, 05 Nov 2020 01:10:34 GMT
ETag: "8-5b351c34ed680"
Accept-Ranges: bytes
Content-Length: 8
Content-Type: text/html

Foo Test%

$ curl -i 127.0.0.1
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

I wonder why 127.0.0.1 is rejected

drbyte on 5 Nov 2020

Ha, you and me both!

mikepostma on 5 Nov 2020

I meant to ask awhile back ... have you any special configurations set up with your various network "interfaces"?

eg: ethernet/wifi/loopback/etc

What's ifconfig show? (I'm rusty on interpreting its output though)

drbyte on 5 Nov 2020

Valet has no built-in facility for generating/managing Apache vhost configs, else I'd be tempted to suggest you use Apache for the time being.
But you might be fine if you're comfortable configuring vhosts by hand, at least for your current projects.

drbyte on 5 Nov 2020

Not that I'm aware of, pretty standard setup here. Output for ifconfig:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=400<CHANNEL_IO>
    ether 60:f8:1d:c1:e7:98 
    inet6 fe80::1c76:ece5:ea0d:840a%en0 prefixlen 64 secured scopeid 0x4 
    inet 192.168.86.239 netmask 0xffffff00 broadcast 192.168.86.255
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=460<TSO4,TSO6,CHANNEL_IO>
    ether 82:0f:1e:a5:ff:c0 
    media: autoselect <full-duplex>
    status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=460<TSO4,TSO6,CHANNEL_IO>
    ether 82:0f:1e:a5:ff:c1 
    media: autoselect <full-duplex>
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 82:0f:1e:a5:ff:c0 
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x0
    member: en1 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 5 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 6 priority 0 path cost 0
    nd6 options=201<PERFORMNUD,DAD>
    media: <unknown type>
    status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    options=400<CHANNEL_IO>
    ether 02:f8:1d:c1:e7:98 
    media: autoselect
    status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
    options=400<CHANNEL_IO>
    ether ae:4f:62:ac:67:bb 
    inet6 fe80::ac4f:62ff:feac:67bb%awdl0 prefixlen 64 scopeid 0x9 
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
llw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=400<CHANNEL_IO>
    ether ae:4f:62:ac:67:bb 
    inet6 fe80::ac4f:62ff:feac:67bb%llw0 prefixlen 64 scopeid 0xa 
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet6 fe80::5d7d:9541:be59:dd16%utun0 prefixlen 64 scopeid 0xb 
    nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
    inet6 fe80::fe52:6304:5592:58f9%utun1 prefixlen 64 scopeid 0xc 
    nd6 options=201<PERFORMNUD,DAD>
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet6 fe80::5470:a86b:89ba:b3a8%utun2 prefixlen 64 scopeid 0xd 
    nd6 options=201<PERFORMNUD,DAD>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet6 fe80::f041:a79f:65cf:90fd%utun3 prefixlen 64 scopeid 0xe 
    nd6 options=201<PERFORMNUD,DAD>

mikepostma on 5 Nov 2020

Valet has no built-in facility for generating/managing Apache vhost configs, else I'd be tempted to suggest you use Apache for the time being.
But you might be fine if you're comfortable configuring vhosts by hand, at least for your current projects.

I am, that's what I used to do before I switched over to Valet. The only one that's working is localhost though. I set up a quick one using a .test domain and that's just doing the same old ERR_CONNECTION_REFUSED.

mikepostma on 5 Nov 2020

<VirtualHost _default_:80>
ServerName localhost

Does changing _default_ to * change whether it'll respond to 127.0.0.1?

and/or changing ServerName from localhost to foo.test ?

drbyte on 5 Nov 2020

Sorry for the radio silence, I installed and uninstalled ExpressVPN 2 more times out of pure frustration and things are suddenly coming back to live it seems. Just give me a few minutes to keep poking around.

mikepostma on 5 Nov 2020

We're all back to normal. For anyone finding this in the future, I'm not a 100% sure what combination of changes ultimately fixed the issue, but I'm pretty sure the issue was originally caused by the installation of ExpressVPN and ultimately solved again by a fresh installation of ExpressVPN.

@drbyte thank you so much for hanging in there and being relentless in trying to track down the issue. It's very much appreciated!

mikepostma on 5 Nov 2020

👍1

Thanks for starting off with a thorough initial incident report. That makes providing help soooooo much easier!

Glad you got it sorted out.

drbyte on 5 Nov 2020

👍1

Was this page helpful?

0 / 5 - 0 ratings