$_SERVER['SERVER_ADDR']和gethostbyname(gethostname())在虚拟机中不可靠，因返回的是监听地址或内网解析结果；应通过环境变量（如PHP_HOST_IP）手动配置宿主机可访问的IP。
在虚拟机里用 PHP 的 $_SERVER['SERVER_ADDR'] 或 gethostbyname(gethostname()) 拿到的几乎总是 127.0.0.1 或内网地址（比如 192.168.56.1），不是你宿主机实际能访问的 IP。这不是 PHP 写错了，是网络栈和虚拟化层根本没把“对外可见的本机 IP”暴露给 PHP 进程。
为什么 $_SERVER['SERVER_ADDR'] 在 VirtualBox/VMware 里不可靠
这个值来自 Web 服务器（如 Apache/Nginx）绑定的监听地址，而虚拟机默认只监听 127.0.0.1 或私有网段。即使你配了桥接模式，PHP 也看不到宿主机视角下的“那个 IP”。更麻烦的是，Docker 容器、WSL2、Vagrant 等环境表现还不一致——有的返回容器网关，有的返回 loopback，全看网络模式和 host 配置。
-
$_SERVER['SERVER_ADDR']是服务器监听地址，不是“本机对外 IP” -
gethostbyname(gethostname())解析的是虚拟机自己的 hostname，通常指向/etc/hosts里配的内网地址 - 没有系统级 API 能直接问“宿主机怎么连我”，PHP 层无法自动推断
手动配置 + 环境变量是最稳的校准方式
别指望自动发现。把真实可用的 IP（比如宿主机能访问的 192.168.1.105 或 10.0.2.15）明确告诉 PHP，它才不会猜错。
- 在虚拟机启动脚本或 Web 服务器环境里设环境变量：
export PHP_HOST_IP="192.168.1.105" - PHP 中读取：
$_ENV['PHP_HOST_IP']或getenv('PHP_HOST_IP') - Nginx 配置中可透传：
fastcgi_param PHP_HOST_IP $server_addr;（需确保$server_addr是你想要的） - 如果用 Docker，直接
-e PHP_HOST_IP=172.17.0.1启动容器
用 HTTP 请求头反向识别（仅限 Web 场景）
如果你的服务始终通过宿主机浏览器访问（比如 http://192.168.1.105:8000），可以信任 $_SERVER['HTTP_HOST'] 的域名/IP 部分——但它不适用于 CLI、定时任务或 API 调用。
立即学习“PHP免费学习笔记（深入）”；
- 提取 IP：
$host = $_SERVER['HTTP_HOST'] ?? ''; $ip = preg_replace('/:\d+$/', '', $host); - 注意：HTTPS 重定向、反向代理（Nginx/Apache）、Host 头伪造都会让这招失效
- 永远要 fallback 到环境变量，不能只靠这个
避免踩 gethostbyname(gethostname()) 的坑
这条“经典写法”在绝大多数虚拟机里都失效，因为 gethostname() 返回的是虚拟机名（如 ubuntu-focal），而 /etc/hosts 里往往把它映射到 127.0.1.1 或一个内网地址。
- 检查结果：
var_dump(gethostbyname(gethostname()));—— 很可能输出"127.0.1.1" - 修复方法：改
/etc/hosts不推荐，容易被 cloud-init 或系统更新覆盖 - 真正需要的是“服务可访问地址”，不是“机器名解析结果”
最易被忽略的一点：IP 校准不是一次性的。换网络（从公司 Wi-Fi 切到手机热点）、切虚拟网络模式（NAT → 桥接）、升级 Vagrant box，都可能让旧 IP 失效。环境变量方案之所以可靠，是因为它把“谁负责知道 IP”这件事，从 PHP 推给了运维或启动流程——而那里才是该知道的地方。
