之前在用到valet的时候就觉得这个工具很厉害，因为本地部署很多时候都是比较费劲的，也比较简陋，就直接localhost启动下，但是有时候需要验一下回调的，就需要有域名跟https，当然之前也没想明白的是在本地其实用本地的地址也是可以的，意思就是如果回调地址没限制必须要域名，也可以用127.0.0.1或者localhost，当然如果需要域名和https那就正好是valet的用武之地，所以想把 Valet 这类工具背后的逻辑捋一下。
平时用 Valet 的时候体验是非常顺的：
1 | valet park |
然后浏览器里访问：
1 | https://demo.test |
就能看到本地项目，而且还有 HTTPS 的小锁。
这个体验乍一看很像魔法。一个本地域名，既不用手动写 hosts，也不用自己配 Nginx，还不用去公网 CA 申请证书，怎么就能跑起来了呢？
其实拆开之后，Valet 并没有发明什么新协议，它只是把本地开发里几件比较麻烦的事情串起来了：
1 | 本地域名解析 |
先放一个整体流程，后面再一段一段拆。
假设我们访问：
1 | https://demo.test/users/1 |
整个过程大概是：
1 | 浏览器访问 https://demo.test/users/1 |
所以可以先得出一个粗略结论：
1 | DNS 负责把域名带到本机 |
这个结论很重要，因为很多时候我们排查 Valet 问题，就是在判断链路断在哪一层。
比如：
1 | 域名打不开，可能是 DNS/dnsmasq 问题 |
源码里可以先看 Configuration.php。
Valet 会在用户目录下维护一个自己的配置目录：
1 | ~/.config/valet |
这个目录下面会有几类东西：
1 | ~/.config/valet/config.json |
从源码看，Configuration::install() 做的事情就是创建这些基础目录，并确保基础配置存在。
其中最核心的是：
1 | config.json |
它大概长这样：
1 | { |
这几个字段分别代表：
1 | tld 本地域名后缀，默认是 test |
所以 Valet 的状态不是凭空来的，它有一个非常明确的落盘位置。
比如 valet park 之后，当前目录会被写到 paths 里。
比如 valet link demo 之后，~/.config/valet/Sites/demo 里会出现一个指向真实项目目录的符号链接。
比如 valet secure demo 之后，证书会进入：
1 | ~/.config/valet/Certificates |
对应的 Nginx 站点配置会进入：
1 | ~/.config/valet/Nginx |
理解这个目录很有用，因为后面很多问题都可以直接去这里看。
我们平时执行：
1 | valet install |
它背后不是单纯装一个命令，而是在本机准备一整套本地 Web 开发环境。
从源码结构上看，大体可以分成几部分：
1 | Configuration.php 创建 ~/.config/valet 相关目录和 config.json |
这里先不展开 PHP 版本管理和 sudoers 等细节，只看主链路。
Valet 安装完成后，本机基本会形成这么一个结构：
1 | macOS DNS |
也就是说，Valet 的轻量不是说它什么服务都没有，而是它复用了本机的 Nginx、PHP-FPM、dnsmasq，不需要为每个项目单独开一个虚拟机或容器。
先看第一个问题：
1 | demo.test 怎么就指向 127.0.0.1 了？ |
如果不用 Valet，我们最容易想到的方法是改 /etc/hosts：
1 | 127.0.0.1 demo.test |
但这样有个问题：每加一个项目，就要写一行。
Valet 不这么做。它用的是 dnsmasq 加 macOS resolver。
源码里对应的是 DnsMasq.php。
DnsMasq::install() 的流程大概是：
1 | 确保 dnsmasq 已安装 |
这里有两个关键文件。
第一个是类似这样的 dnsmasq 配置：
1 | address=/.test/127.0.0.1 |
它的意思是：
1 | 所有 .test 结尾的域名，都解析到本机 |
所以这些域名都可以成立：
1 | demo.test |
第二个是：
1 | /etc/resolver/test |
内容大概是：
1 | nameserver 127.0.0.1 |
这个文件告诉 macOS：
1 | 遇到 .test 这个后缀，不要走普通 DNS，交给 127.0.0.1 上的 DNS 服务处理 |
然后本地的 dnsmasq 再把它解析回 127.0.0.1。
这里要注意一件事：DNS 这一层只解决了“域名到 IP”的问题。
也就是说：
1 | demo.test -> 127.0.0.1 |
但是 DNS 并不知道：
1 | demo.test 对应哪个项目目录 |
这个问题要留给后面的 Nginx 和 Valet 自己处理。
域名解析到 127.0.0.1 之后，浏览器会根据协议和端口发请求。
如果是 HTTP：
1 | http://demo.test -> 127.0.0.1:80 |
如果是 HTTPS：
1 | https://demo.test -> 127.0.0.1:443 |
这时接请求的是 Nginx。
源码里对应的是 Nginx.php。
Nginx::install() 大致做几件事：
1 | 确保 Nginx 已安装 |
这里比较关键的是 Valet 的 Nginx 不是简单地给某一个项目写死 root。
它会准备一个统一入口，把请求转给 Valet 自己的 server.php。
可以粗略理解为：
1 | Nginx 接住所有本地 .test 请求 |
这一点是 Valet 设计里比较关键的地方。
如果完全靠 Nginx，每个项目都要生成一个完整的 server block：
1 | demo.test -> /Users/me/code/demo/public |
Valet 当然也会为 HTTPS、proxy、PHP 隔离这类特殊场景生成站点配置，但普通场景下，它更核心的思路是：
1 | Nginx 做入口 |
这样它才能做到 valet park 之后，目录下面新增一个项目，不需要手工改 Nginx 配置也能访问。
接着看项目目录映射。
Valet 常用两个命令：
1 | valet park |
它们都能让本地域名对应到项目，但思路不一样。
假设我们在这个目录执行：
1 | cd ~/Sites |
然后目录结构是：
1 | ~/Sites/demo |
Valet 就可以让这些域名工作：
1 | demo.test -> ~/Sites/demo |
从配置角度看，park 主要就是把 ~/Sites 这个路径写入 config.json 的 paths。
之后 Valet 查找站点时，会扫描这些 parked path 下面的子目录。
所以 park 的心智模型是：
1 | 我把一个工作区交给 Valet |
link 更像是给当前目录起一个名字。
比如：
1 | cd ~/code/some-long-project-name |
它会创建类似这样的符号链接：
1 | ~/.config/valet/Sites/demo -> ~/code/some-long-project-name |
之后：
1 | demo.test |
就对应这个真实项目目录。
源码里 Site::link() 做的事情也很直接：
1 | 确保 ~/.config/valet/Sites 存在 |
所以可以这样理解：
1 | park 是目录扫描 |
这也是排查时很好用的判断。
如果是 park 出来的站点，要看父目录有没有在 config.json 的 paths 里。
如果是 link 出来的站点，要看 ~/.config/valet/Sites 下的符号链接是否存在、是否指向正确目录。
现在 DNS 和 Nginx 都说完了，请求已经进入 Valet。
真正处理请求分发的是仓库根目录下的：
1 | server.php |
这段源码非常值得看，因为它基本把 Valet 的请求生命周期写清楚了。
它做的事情可以简化成这样：
1 | $config = read_valet_config(); |
这里面有几个关键点。
第一个，siteName 来自 HTTP Host。
访问：
1 | demo.test |
Valet 会从 Host 里解析出：
1 | demo |
第二个，sitePath 来自 Valet 的站点映射。
也就是前面说的：
1 | parked paths |
第三个，Valet 不会一上来就假设这是 Laravel 项目，而是会通过 driver 选择。
这一层是 Valet 能支持很多框架的关键。
源码里 ValetDriver.php 定义了几个关键方法：
1 | serves() |
这三个方法基本就回答了三个问题：
1 | 这个 driver 能不能处理当前项目？ |
比如 Laravel 项目的 driver，也就是 LaravelValetDriver.php，判断逻辑可以概括成：
1 | 项目目录下有 public/index.php |
这就很符合 Laravel 项目的基本结构。
对于静态文件，它会优先找：
1 | 项目目录/public/当前 URI |
如果请求的是：
1 | /css/app.css |
并且真实文件存在：
1 | public/css/app.css |
那就直接返回静态文件。
如果请求的是：
1 | /users/1 |
这显然不是一个真实静态文件，那就交给：
1 | public/index.php |
然后 Laravel 自己的路由系统再接着处理。
这就是 Valet driver 的意义。
Nginx 并不知道 Laravel、WordPress、Statamic、普通 PHP 项目的入口规则有什么区别。Valet 通过 driver 把这些规则封装起来。
所以 Valet 支持多框架的本质不是 Nginx 有多聪明，而是：
1 | server.php 统一接管请求 |
Valet 处理静态文件还有一个有意思的细节。
在 driver 判断某个请求是静态文件后，它不是简单地在 PHP 里 readfile()。
Valet driver 会通过一个内部跳转机制，让 Nginx 去返回真实文件。
也就是类似：
1 | PHP 判断这是静态文件 |
这么做的好处是：
1 | PHP 只负责判断逻辑 |
这也符合 Web Server 和应用层的分工。
Nginx 擅长处理静态文件，PHP 擅长处理动态逻辑。
再说一下 PHP-FPM。
Nginx 自己不会执行 PHP。
当请求需要执行 server.php 或项目的 public/index.php 时，Nginx 会把请求交给 PHP-FPM。
Valet 里常见的通信方式是 Unix socket，比如：
1 | ~/.config/valet/valet.sock |
可以粗略理解成：
1 | Nginx 是前台 |
Nginx 接到请求后，如果需要执行 PHP，就把请求交给 PHP-FPM。
PHP-FPM 执行完 PHP 脚本，再把响应交回给 Nginx，最后返回给浏览器。
这也解释了为什么有时候 Valet 域名能解析、Nginx 也启动了，但页面仍然打不开，可能是 PHP-FPM 没起来，或者 socket 路径不对。
现在再看 HTTPS。
问题是：
1 | 为什么 https://demo.test 能有小锁？ |
公网 HTTPS 的常见逻辑是：
1 | 浏览器内置信任一批根 CA |
本地 HTTPS 没法直接去公网 CA 申请 demo.test 的证书，因为它不是公网真实站点。
Valet 的思路是：
1 | 自己创建一个本地 CA |
也就是：
1 | Laravel Valet 本地 CA |
这里最关键的一句话是：
1 | 浏览器信任的不是 demo.test 这个域名本身，而是它的证书链能追溯到系统信任的 CA。 |
所以 Valet 本地 HTTPS 的本质是：
1 | 本地生成证书 |
这个信任只在你的机器上成立。
换一台电脑，如果没有信任你这台机器上的 Valet CA，demo.test 的证书就不会被认为可信。
源码里 HTTPS 的主线在 Site.php。
valet secure demo 最终会走到类似 Site::secure() 的逻辑。
它的主流程可以整理成：
1 | 保留当前站点可能存在的 PHP 版本隔离配置 |
里面又可以拆成两个层次。
createCa() 负责创建本地 CA。
它会生成类似这些文件：
1 | ~/.config/valet/CA/LaravelValetCASelfSigned.pem |
然后通过 macOS 的 security 命令把这个 CA 加入系统钥匙串。
也就是告诉系统：
1 | 这个本地 CA 我信任 |
这是小锁能出现的根本原因。
如果这一步失败，比如钥匙串没有信任成功，证书就算生成了，浏览器也可能不认。
createCertificate() 负责给具体域名生成证书。
比如：
1 | demo.test.key |
这些文件放在：
1 | ~/.config/valet/Certificates |
流程大概是：
1 | 生成私钥 |
所以证书关系是：
1 | CA 私钥 + CA 证书 |
这和公网证书的逻辑是类似的，只是 CA 从公网机构换成了你本机的本地 CA。
只生成证书还不够。
Nginx 还得知道：
1 | demo.test 用哪张证书 |
Site::buildSecureNginxServer() 会读取 Valet 的 HTTPS Nginx 模板，然后把占位符替换成真实值。
大概会替换这些东西：
1 | VALET_SITE -> demo.test |
所以 valet secure demo 之后，Nginx 站点配置就会知道：
1 | server_name demo.test |
同时它还会保留 Valet 的基本请求分发逻辑：
1 | HTTPS 请求进来 |
也就是说，HTTPS 只是入口层多了一次证书和 TLS 处理，后面的项目分发逻辑并没有变。
这里稍微提一下 SNI，但不展开太远。
本机可能同时有很多 HTTPS 站点：
1 | demo.test |
它们都走：
1 | 127.0.0.1:443 |
那 Nginx 怎么知道应该拿哪张证书？
客户端在 TLS 握手时会带上要访问的域名，这就是 SNI。
Nginx 根据这个域名匹配对应的 server block，然后选择对应证书。
所以访问：
1 | https://demo.test |
Nginx 会用 demo.test 的证书。
访问：
1 | https://blog.test |
Nginx 会用 blog.test 的证书。
这也是为什么 server_name 和证书配置要对应起来。
Valet 还有一个很实用的功能：
1 | valet proxy api http://127.0.0.1:3000 |
这个功能不是 PHP 项目映射，而是 Nginx 反向代理。
它的意思是：
1 | api.test |
源码里也在 Site.php，对应 proxyCreate() 这类逻辑。
它会生成一份 Nginx proxy 配置，把 api.test 的流量转发到指定地址。
如果加上 secure，本质就是：
1 | 给 api.test 生成本地证书 |
所以 Valet 不只能服务 Laravel 或 PHP 项目。对于 Node、Go、Docker 暴露出来的本地端口，Valet 也可以提供一个统一的本地域名和本地 HTTPS 入口。
现在把源码文件和职责再汇总一下。
1 | Configuration.php |
负责 Valet 自己的配置目录和 config.json：
1 | tld |
1 | DnsMasq.php |
负责 .test 这类本地域名后缀：
1 | /etc/resolver/test |
1 | Nginx.php |
负责安装和写入 Valet 的 Nginx 配置：
1 | nginx.conf |
1 | Site.php |
负责站点层面的事情：
1 | link |
1 | server.php |
是每次请求真正进入的 Valet 分发入口：
1 | 解析 Host |
1 | ValetDriver.php |
定义项目识别和入口判断的抽象：
1 | serves() |
1 | LaravelValetDriver.php |
是 Laravel 项目的具体规则：
1 | 有 artisan |
这几个文件串起来，就能看到 Valet 的整体设计。
理解了链路之后，排查也会清楚很多。
可以看：
1 | cat /etc/resolver/test |
以及：
1 | cat ~/.config/valet/dnsmasq.d/tld-test.conf |
如果这里不对，问题通常还没到 Nginx。
可以看：
1 | cat ~/.config/valet/config.json |
如果是 park，看 paths 里有没有父目录。
如果是 link，看：
1 | ls -l ~/.config/valet/Sites |
可以看：
1 | ls ~/.config/valet/Nginx |
如果是 secure 或 proxy 站点，这里一般会有对应配置。
可以看：
1 | ls ~/.config/valet/Certificates |
也可以检查本地 CA：
1 | ls ~/.config/valet/CA |
如果 Nginx 能接请求，但 PHP 执行异常，就要看 PHP-FPM 和 socket。
Valet 的 Nginx 配置会把 PHP 请求交给类似：
1 | ~/.config/valet/valet.sock |
如果这个 socket 不存在，或者 PHP-FPM 没启动，就会出问题。
Valet 的原理可以压缩成一句话：
Valet 用 dnsmasq 解决本地域名，用 Nginx 接住请求，用 server.php 和 driver 找到真正项目入口，用 PHP-FPM 执行 PHP，再用本地 CA 和 Nginx 配置补上 HTTPS。
它的好用之处不是某个单点技术特别神奇，而是把一堆本来要手工处理的事情自动化了：
1 | 不用每个项目手写 hosts |
如果只看表面，Valet 好像只是让 demo.test 能访问。
但从源码和链路看，它其实是给本地开发搭了一套很轻量的“入口网关”：
1 | 所有本地域名都先进本机 |
理解这一点之后，再看 valet park、valet link、valet secure、valet proxy，就不太像魔法了。
它们只是分别在这条链路上改了一小段配置。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。