search

laravel / valet

A more enjoyable local development experience for Mac.
https://laravel.com/docs/valet
MIT License
2.52k stars 698 forks source link

This site can't be reached / ERR_CONNECTION_REFUSED #989

Closed mikepostma closed 4 years ago

mikepostma commented 4 years ago

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.

drbyte commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Among other things, I'd be exploring:

mikepostma commented 4 years ago

Thanks for all the great suggestions.

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

to

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.

mikepostma commented 4 years ago

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
brew list --versions | grep -E "(php|nginx|dnsmasq|mariadb|mysql|mailhog|openssl)(@\d\..*)?\s" 
curl-openssl 7.73.0
dnsmasq 2.82
nginx 1.19.4
openssl@1.1 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: openssl@1.1, 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, openssl@1.1, 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

openssl@1.1: stable 1.1.1h (bottled) [keg-only]
Cryptography and SSL/TLS Toolkit
https://openssl.org/
/usr/local/Cellar/openssl@1.1/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/openssl@1.1.rb
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/openssl@1.1/certs

and run
  /usr/local/opt/openssl@1.1/bin/c_rehash

openssl@1.1 is keg-only, which means it was not symlinked into /usr/local,
because macOS provides LibreSSL.

If you need to have openssl@1.1 first in your PATH run:
  echo 'export PATH="/usr/local/opt/openssl@1.1/bin:$PATH"' >> ~/.zshrc

For compilers to find openssl@1.1 you may need to set:
  export LDFLAGS="-L/usr/local/opt/openssl@1.1/lib"
  export CPPFLAGS="-I/usr/local/opt/openssl@1.1/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 homebrew.mxcl.php@7.3.plist


            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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?
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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?
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

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

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
worth checking


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

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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)
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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)
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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;
}
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

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

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

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

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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.
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
Really appreciate the realtime support by the way!
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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
                commented
                 4 years ago            

            

                


Really appreciate the realtime support by the way!




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

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

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

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

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

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
/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
                commented
                 4 years ago            

            

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

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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.
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                


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
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                mikepostma
                commented
                 4 years ago            

            

                
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.
            

        

            

            

                drbyte
                commented
                 4 years ago            

            

                
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
                commented
                 4 years ago            

            

                
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").