Valet Loading name.localhost externally - DNS not Resolved / Connection Refused

Help
1

  • Trying to make Laravel Valet work with Ngrok serving a local WordPress site for other pcs and phones not part of the network.

  • Issues: Many things written down here at Stack Overflow. Seems DNS cannot be resolved. Caddy serves all files correctly and does not show any server errors related to the issue. Ngrok keeps on mentioning redirects. Browsers say either connection is refused or DNS cannot be resolved.
    Redirect mention;

    HTTP/1.1 301 Moved Permanently
    Content-Type: text/html; charset=UTF-8
    Location: http://rocketpure.localhost/
    Server: Caddy
    Status: 301 Moved Permanently
    X-Powered-By: PHP/7.0.11
    X-Ua-Compatible: IE=edge
    Date: Mon, 03 Oct 2016 11:22:54 GMT
    Content-Length: 0

Last caddy access log lines:

::1 - [03/Oct/2016:14:26:16 +0300] "POST /server.php HTTP/1.1" 200 47
127.0.0.1 - [03/Oct/2016:14:28:16 +0300] "POST /server.php?doing_wp_cron=1475494096.3714780807495117187500 HTTP/1.1" 200 0
::1 - [03/Oct/2016:14:28:17 +0300] "POST /server.php HTTP/1.1" 200 47
127.0.0.1 - [03/Oct/2016:14:30:24 +0300] "POST /server.php?doing_wp_cron=1475494223.3111729621887207031250 HTTP/1.1" 200 0
::1 - [03/Oct/2016:14:30:24 +0300] "POST /server.php HTTP/1.1" 200 47
127.0.0.1 - [03/Oct/2016:14:31:17 +0300] "GET /server.php?action=load_cache&stream_id=1&force= HTTP/1.1" 200 1

Caddyfile generated by Valet:

import /Users/jasper/.valet/Caddy/*

:80 {
    fastcgi / 127.0.0.1:9000 php {
        index server.php
    }

    rewrite {
        to /server.php?{query}
    }

    log /Users/jasper/.valet/Log/access.log {
        rotate {
            size 10
            age 3
            keep 1
        }
    }

    errors {
        log /Users/jasper/.valet/Log/error.log {
            size 10
            age 3
            keep 1
         }
    }
}

Going really crazy here and need it up or move to another option. Decided to post here as Valet uses Caddy and Ngrok. Asked Ngrok for help, but no response yet. At SO no answers yet either. Could be totally an Ngrok issue, but would like to make sure the Caddy Setup is OK and son. Appreciate the feedback!

2

Looks like your PHP app expects your hostname to be rocketpure.localhost instead of whatever ngrok is tunneling it through (the xxxxx.ngrok.io thing, which is where clients are actually making their requests… I presume). It sees a different hostname so it’s redirecting to a host that can’t be reached through ngrok.

So this doesn’t appear to be an issue with Caddy, but I hope you figure it out soon!

1 Like
3

Yeah, well it does hit my Mac Mini and shows these headers in the NGrok control panel at localhost:4040. The PHP script tells Ngrok the site is at site.localhost:80 and run that as a header rewrite:

ps aux | grep ngrok
jasper          15781   0.2  0.2 556709828  25416 s001  S+    8:30AM   0:02.52 /Users/jasper/.composer/vendor/laravel/valet/bin/ngrok http -host-header=rewrite site.localhost:80
jasper          15846   0.0  0.0  2432804   2096 s000  S+    8:37AM   0:00.00 grep ngrok
root            15775   0.0  0.1  2463108   8956 s001  S+    8:30AM   0:00.01 sudo -u jasper /Users/jasper/.composer/vendor/laravel/valet/bin/ngrok http -host-header=rewrite site.localhost:80

and then the script and or Caddy tells it it has moved.

GET / HTTP/1.1
Host: site.localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: */*
Accept-Charset: ISO-8859-1;utf-8;q=0.7,*;q=0.7
Cache-Control: max-age=259200
Referer: 45.79.9.205
X-Forwarded-For: 159.203.4.15
X-Original-Host: a6bcc8d3.ngrok.io

redirect:

HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://site.localhost/
Server: Caddy
Status: 301 Moved Permanently
X-Powered-By: PHP/7.0.11
X-Ua-Compatible: IE=edge
Date: Tue, 04 Oct 2016 05:31:29 GMT
Content-Length: 0

It tells that it has moved to the same address, only with http before the domain and a slash at the end. In the access logs I see this:

127.0.0.1 - [04/Oct/2016:08:31:00 +0300] "POST /server.php?doing_wp_cron=1475559060.4815170764923095703125 HTTP/1.1" 200 0
::1 - [04/Oct/2016:08:31:01 +0300] "POST /server.php HTTP/1.1" 200 47
127.0.0.1 - [04/Oct/2016:08:31:18 +0300] "GET /server.php HTTP/1.1" 301 0
127.0.0.1 - [04/Oct/2016:08:31:29 +0300] "POST /server.php?doing_wp_cron=1475559088.8387360572814941406250 HTTP/1.1" 200 0
127.0.0.1 - [04/Oct/2016:08:31:29 +0300] "GET /server.php HTTP/1.1" 301 0
127.0.0.1 - [04/Oct/2016:08:33:01 +0300] "POST /server.php?doing_wp_cron=1475559181.5188720226287841796875 HTTP/1.1" 200 0

So WordPress seems to notice and run its cron job as well… Very odd.

4

Does this happen without ngrok? I don’t know what to suggest at this point except try removing elements of your setup until the redirect stops.

5

Without using Ngrok I can visit all pages and in the logs I then see:

::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=1.4.1 HTTP/1.1" 200 1412
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=2.6.4 HTTP/1.1" 200 277
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=2.6.4 HTTP/1.1" 200 2401
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=4.6.1 HTTP/1.1" 200 1078
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=4.6.1 HTTP/1.1" 200 833
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=3.5.3 HTTP/1.1" 200 359665
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php?ver=4.6.1 HTTP/1.1" 200 1403
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php HTTP/1.1" 200 569389
::1 - [04/Oct/2016:19:40:02 +0300] "GET /server.php HTTP/1.1" 200 206
127.0.0.1 - [04/Oct/2016:19:40:18 +0300] "GET /server.php?action=load_cache&stream_id=1&force= HTTP/1.1" 200 1

Also wondered whether it was ipv4/6 related, but in the logs you see regular localhost and ::1 being loaded just fine. No redirects this way as you can see. So it either is the script dealing with the conversion of the Ngrok domain to a local domain or Ngrok itself. Opened a thread with Valet as well and asked Ngrok for some advice. Gut feeling says it is a Laravel Valet thing. Opened an issue there so we shall see. Will keep you guys updated.

1 Like
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.