企业官网建设流程全解析

做PHP开发这些年，“PHP网站跳转不携带域名”这个问题每隔一阵就会冒出来一次，而且每次都是差不多的配方：用户在A页面点了一个按钮，浏览器地址栏里唰地跳到一截不完整的URL上，要么域名消失只剩路径，要么直接跳到localhost或者某个内网地址，要么https活生生跳成了http。团队里第一次遇到这种问题的人，往往会把业务代码翻个底朝天，最后发现根本不是业务逻辑的锅。这篇文章把我这些年排查这类问题的经验整理出来，按“先看现象→再讲原理→给定位链路→给解决方案”的顺序展开，适合那些写完header('Location')本地能跑、一上线就翻车的PHPer，也适合接手老项目时面对一堆跳转逻辑不知道怎么下手的人。

1. 先看清楚：跳转丢域名到底有哪几种“长相”

1.1 现象一：Location头变成了半截路径

这是最隐蔽的一种。你打开浏览器开发者工具，找到那条302跳转请求，看响应头里的Location，长这样：

HTTP/1.1 302 Found Location: /admin/dashboard

注意这里连“http://”都没有，就是一个以斜杠开头的绝对路径。浏览器拿到这种地址不会报错，它会自动拿当前页面的域名去补齐，最终跳转到的URL可能是https://www.example.com/admin/dashboard，看起来居然完全正常。所以很多同学压根不会意识到这里埋了雷。

但这个雷什么时候会爆？当你的站点可以通过多个域名访问、或者前面隔着一层反向代理时。同一个相对路径，在不同的页面URL、不同的代理入口下，会被拼出完全不同的结果。比如当前页面是https://www.example.com/subdir/index.php，如果代码里写的是不带起始斜杠的Location: login.php，浏览器会认为目标是当前目录下的login.php，拼出来变成https://www.example.com/subdir/login.php，和你想去的https://www.example.com/login.php根本不是同一个地址。

1.2 现象二：一跳就回到localhost或内网地址

这个现象就直白多了。用户明明访问的是线上域名，点完跳转之后，地址栏变成了http://localhost:8080/user/index，页面上全是“无法访问此网站”。开发者在本地用PHP内置服务器跑的时候，访问地址就是http://localhost:8080，代码里如果直接用了这个地址来拼接跳转目标，本地一切正常，一旦部署到线上或者换台机器就完全崩了。

还有一种相似的情况是跳转到了内网IP，比如http://127.0.0.1:9000/xxx。这说明后端收到的请求头里，Host已经被某个中间环节改成了后端内部地址，PHP程序毫不知情，照样拿它拼URL。

1.3 现象三：https在跳转过程中“降级”

这类问题的表现是：页面明明是通过https://www.example.com访问的，点一个跳转，浏览器却提示“您与此网站之间建立的连接不安全”，一看地址栏，已经变成了http://www.example.com。注意，域名没丢，端口没丢，唯独协议错了。

这种降级通常发生在“SSL终结”之后。也就是所有https请求先被Nginx或者某种负载均衡设备解密，然后以普通http请求转发给后端PHP服务。PHP程序看到的请求连接是http，那么它按当前请求协议去生成的新URL，自然也是http开头。跳转目标里只要有一处全站强制https的逻辑漏掉了，用户就会被带偏。

我把三个典型现象汇总成了一张表，方便你对着排查：

2. 从HTTP协议到PHP取值：丢域名的根因到底在哪

2.1 header('Location')并不是什么魔法

很多新手会把header('Location: ...')当成PHP的“跳转方法”，其实它做的事情特别单纯：往HTTP响应里塞一行“Location: xxx”头。究竟跳不跳、跳到哪，是浏览器根据这行响应头决定的，服务端根本管不到后续。

服务器返回一个3xx状态码（最常见的是301和302），浏览器读到响应头里的Location，再决定发起新的GET请求。也就是说，跳转是否携带域名，本质上是看你写到Location头里的那串字符串长什么样。如果你写了一个相对路径，那实际上你是把这件“补全域名”的活儿丢给了浏览器；不同页面URL下，浏览器补全的基准还不一样。

2.2 $_SERVER里的域名，是请求“喂”给你的

PHP代码里最常用的取域名方式是$_SERVER['HTTP_HOST']，但很多人不清楚它的来源。HTTP/1.1协议要求客户端在请求时必须携带Host头，$_SERVER['HTTP_HOST']就是PHP从请求头里读出来的Host字段，它代表的是“客户端认为自己在访问哪个主机”，而不是“服务器配置里写死的主机名”。

这个区别很关键。当你的架构里有一层Nginx或者负载均衡设备时，请求链路是这样的：客户端 → Nginx → PHP-FPM。Nginx收到请求后，默认会把原始Host头原样转发给后端，所以PHP拿到的还是用户访问时的域名，没问题。但如果配置里写了类似proxy_set_header Host localhost:8080;这样的指令，Nginx就会用这个固定值覆盖掉原始的Host头，PHP再读$_SERVER['HTTP_HOST']，拿到的就是localhost。跳转不携带域名？不，问题往往不是没带，而是带了错误的值。

2.3 Location支持相对地址，但“相对”的基准取决于当前页面

我见过不少同学以为Location就必须写完整URL，所以一旦代码里出现Location: /admin，他们还会觉得“这没问题，PHP会自动补全”。实际上PHP完全不会帮你补全任何东西，你写什么，响应头里就是什么。

根据HTTP规范，Location字段既可以是完整URL，也可以是相对引用。浏览器解析相对Location的时候，会拿当前页面的完整URL作为基准。举个例子，当前页面是https://a.com/user/profile，Location写/settings，最终跳转是https://a.com/settings；前面再加点路径，比如当前页面是https://a.com/user/index.php，Location写../login，最终跳转就变成了https://a.com/login。

这也就是为什么“相对路径跳转”那么容易出问题——你在一个URL结构下测试是好的，换个入口进来，整个跳转结果就变了。

2.4 为什么不建议无脑信任$_SERVER['HTTP_HOST']

除了代理导致的篡改问题，$_SERVER['HTTP_HOST']本身还有个安全属性需要注意：它是客户端可控的请求头。一个恶意用户完全可以手动构造一个请求，把Host头改成任何值，PHP这边读到的就是什么值。

如果你直接把$_SERVER['HTTP_HOST']拼进跳转地址，等于把“跳转到哪里”的控制权交给了请求方，这就是业界常说的开放重定向漏洞的雏形。攻击者可以构造一条链接，让正常用户跳转到钓鱼站点。所以正规做法是，要么在服务器层面固定好允许的域名列表，要么在代码里对取到的Host做白名单校验。

3. 三种典型场景的排查路径

3.1 场景A：代码里的域名写死在跳转语句中

这类代码通常长这样：

<?php header('Location: http://localhost:8080/index.php?action=login'); exit;

或者更常见的是在配置文件里定义了一个常量：

<?php define('SITE_URL', 'http://localhost:8080'); header('Location: ' . SITE_URL . '/user/index');

当你把项目从本地搬上服务器，只需要改一个配置，似乎问题不大。但发布流程一旦没有把配置文件纳入版本管理和环境区分，线上和本地就是同一份配置，于是所有跳转目标永远带着localhost。更糟的情况是，项目里有多个文件直接写了域名，你改了一个，漏了另一个，排查时很难快速圈定范围。

这种场景的定位方式很直接：全局搜索跳转语句里有没有硬编码的域名，尤其搜http://、https://。一旦发现，尽量抽出配置或环境变量，不要散落在业务代码里。

3.2 场景B：反向代理把Host头改成固定值

架构稍微复杂一点的项目，前端通常挂一层Nginx做静态处理、负载均衡或者SSL终结。Nginx转发给PHP-FPM的默认行为是保留原始Host，但有些同学为了后端内部接口调试方便，会在配置里把它固定掉。

location / { proxy_pass http://php_backend:9000; proxy_set_header Host localhost:8080; }

这段配置意味着，无论客户端用哪个域名访问，后端PHP收到的Host头永远都是localhost:8080。如果PHP代码里有任何基于$_SERVER['HTTP_HOST']生成链接的地方，跳转必然是错的。

检查方法是看Nginx配置文件里的proxy_set_header，确认Host后面用的是$host或者$http_host，而不是某个写死的字符串。同时还要注意X-Forwarded-Proto有没有正确透传，否则https降级问题也会跟着来。

3.3 场景C：框架或公共配置里的基础地址写错

很多PHP MVC框架都提供了统一的跳转方法，比如redirect('/user/index')。这类方法内部会读一个全局的“基础地址”配置项，用它拼出完整URL。这个配置项通常叫base_url、app_url或者site_url，看具体框架而定。

问题往往出在：这套配置是从开发环境直接拷贝到生产环境的，里面写的是http://localhost:8080；或者是项目迁移过一次域名，老域名的值还留在配置里。框架层所有生成链接的逻辑都基于这个值，一处错，处处错。

定位时先找到框架的公共配置文件，看基础地址的值是否和当前访问域名一致。为了彻底解决，建议把这个值改成从环境变量读取，让不同环境使用各自的配置，而不是手工去改文件。

4. 一次线上问题的完整排查复盘

4.1 现象与初步定位

我曾经接手过一个内部业务系统的线上反馈：用户从某个功能页点击“提交订单”之后，浏览器跳到了一个完全打不开的地址，地址栏显示http://localhost:8080/order/success，但用户访问的入口明明是https://pay.example-biz.com。正常情况下，跳转目标应该是https://pay.example-biz.com/order/success。

接到这种问题，我的第一反应不是急着翻PHP代码，而是先确认一件事：这条跳转到底是服务端返回的302，还是前端JavaScript触发的。两种跳转的产生链路不同，不能混在一起查。

4.2 用命令行验证响应头

在浏览器开发者工具的Network面板里，找到那条302请求，查看Response Headers，里面清楚地写着：

HTTP/1.1 302 Found Location: http://localhost:8080/order/success

看到这个结果，基本可以确定是服务端生成的跳转地址出了问题。为了得到更干净的证据，我直接在服务器上执行了curl命令：

curl -I 'https://pay.example-biz.com/order/create' -H 'Host: pay.example-biz.com'

返回的Location头照样是http://localhost:8080/order/success。这证明外部请求到达入口后，PHP程序生成的跳转地址就是错的，和用户浏览器没有关系。

4.3 顺着PHP看到的请求头继续追

既然Location是PHP生成的，那就看PHP程序眼中的请求信息。我在项目入口文件里临时加了这么一段调试代码：

<?php file_put_contents('/tmp/debug_host.log', json_encode([ 'HTTP_HOST' => $_SERVER['HTTP_HOST'] ?? '', 'SERVER_NAME' => $_SERVER['SERVER_NAME'] ?? '', 'HTTPS' => $_SERVER['HTTPS'] ?? '', 'HTTP_X_FORWARDED_PROTO' => $_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '', ]), FILE_APPEND);

重新访问一次接口，打开日志文件，发现HTTP_HOST显示的是localhost:8080，HTTPS为空。这说明问题既不在业务代码，也不在框架配置，而是PHP服务接收到的请求本身就是错的。继续往上看Nginx配置，果然有一行proxy_set_header Host localhost:8080;，是之前调试后端接口时留下的“临时配置”，后来一直没删。

4.4 修复与验证

把Nginx配置改成保留原始Host，并补上协议透传：

location / { proxy_pass http://php_backend:9000; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto $scheme; }

重启Nginx后，再用curl验证同一接口，Location头已经变成了https://pay.example-biz.com/order/success。完成修复后，我又顺手把入口文件里的临时调试代码删除，避免日志无限增长。

5. 写一个可靠的域名获取方法

5.1 需求拆解：域名获取要考虑哪些输入源

解决这一类问题，最好的办法不是遇到一次修一次，而是做一个统一的“当前站点基础地址”函数，让所有跳转和链接生成都走它。这个函数至少要满足几个条件：能正确识别http和https；在反向代理后也能拿到原始协议；能兼容带端口访问的情况；最关键的是，对拿到的值做合法性过滤，不能让它成为攻击入口。

协议识别的优先顺序需要注意。正常情况下，$_SERVER['HTTPS']已经够用；但处于代理后时，PHP看到的连接是代理发起的http，所以还要看HTTP_X_FORWARDED_PROTO。这个头信息是代理告诉后端的原始协议，必须来自可信代理，否则外部用户可以随便伪造。

5.2 代码实现与防御逻辑

下面是我在项目里长期使用的一个版本，注释就是当时的踩坑记录：

<?php /** * 获取当前站点基础地址 * 示例返回：https://www.example.com 或 http://localhost:8080 */ function getBaseUrl(): string { // 1. 判断协议，优先看代理转发过来的原始协议 $isHttps = false; if (!empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off') { $isHttps = true; } if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO'])) { $proto = strtolower(trim($_SERVER['HTTP_X_FORWARDED_PROTO'])); if ($proto === 'https') { $isHttps = true; } elseif ($proto === 'http') { $isHttps = false; } } // 2. 取主机名，优先用请求头里的Host $host = ''; if (!empty($_SERVER['HTTP_HOST'])) { $host = $_SERVER['HTTP_HOST']; } elseif (!empty($_SERVER['SERVER_NAME'])) { $host = $_SERVER['SERVER_NAME']; } // 3. 严格过滤，只保留域名、IPv6方括号、连字符和端口分隔符 $host = preg_replace('/[^a-zA-Z0-9\-\.\[\]:]/', '', $host); $host = trim($host, '.'); // 4. 组装并返回 $scheme = $isHttps ? 'https' : 'http'; return $scheme . '://' . $host; }

第3步的正则过滤不是可有可无的装饰，它直接防住了Header注入。因为基础地址最终要拼到Location头里，如果Host里混入了回车换行或其它控制字符，攻击者就能往响应头里塞任意字段。虽然HTTP规范本身禁止这种字符出现在请求行里，但放在服务端做一道防御总归更稳妥。

5.3 使用场景：跳转封装与URL生成

有了基础地址函数，再封装一个统一的跳转方法就顺理成章了：

<?php function redirect(string $path): void { // 已带完整协议的地址直接跳 if (preg_match('#^https?://#i', $path)) { header('Location: ' . $path); } else { header('Location: ' . getBaseUrl() . '/' . ltrim($path, '/')); } exit; }

这个函数强制要求开发人员调用跳转时走统一入口，避免散落各处的裸header('Location: ...')。业务代码里只需要写redirect('/order/success')，代码简洁，行为可控。

如果你的项目是那种历史包袱很重、到处是裸跳转的老系统，一次性改造不现实。建议分两步走：先新增这些辅助函数，让新代码和修复过的文件都走统一入口；再逐步排查老代码里的硬编码域名和裸跳转，遇到一个改一个，不追求一天改完，但必须持续推进。

6. 预防措施：让域名问题不再卷土重来

6.1 禁止硬编码域名，强制走环境配置

这是最基础也是最重要的一步。所有对外链接的基础地址，只允许从环境变量或部署配置中读取，不允许散落在业务代码里。例如在入口文件统一加载配置：

<?php // 从环境变量读取，而不是在代码里写死 $baseUrl = getenv('APP_URL') ?: getBaseUrl();

这样做的好处是，不管有多少个环境——本地、测试、预发布、生产——每个环境都能用自己的APP_URL，代码本身不携带任何环境特征，部署时不会出现“代码发过去，域名还留在本地”的尴尬。

（这里省略不必要的空行）

6.2 服务器端配置要点

如果你使用了反向代理，有两条配置需要反复确认：

proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto $scheme;

第一行保证后端拿到的域名和用户访问的一致；第二行保证后端知道原始请求是http还是https。这两行配置务必加到每个location块里，并保证没有其它指令覆盖它们。建议在配置里加注释说明“此处不得修改为固定值”，防止后来的人调试时改成固定Host。

6.3 上线前的跳转自检清单

我后来养成了一个习惯，每次涉及跳转逻辑或部署新环境，上线前一定会做一遍快速自检，步骤不多，但能规避大部分问题：

1. 用浏览器开发者工具走一遍核心流程，看每一条302响应的Location头是不是完整、正确。
2. 用curl带域名直接请求入口，确认服务端返回的Location与预期一致：

curl -I 'https://pay.example-biz.com/order/create'

3. 检查配置文件里的基础地址与当前环境匹配，重点看是不是残留了localhost。
4. 检查代理配置里的Host与X-Forwarded-Proto是否透传。
5. 检查协议是否从https保持到跳转后。

这套清单执行下来，基本不会再有“本地好好的，一上线就跳错”的事故。

（正文结束）

最后再分享一点个人体会：这类跳转问题，表面上是个域名拼接的小事，实际上暴露的是项目对“运行时环境信息”的依赖方式。PHP作为服务端语言，天然能拿到很多环境相关的变量，但能不能安全、稳定地使用它们，取决于开发时有没有把它当“外部输入”来对待。我自己现在接手任何项目，第一件事就是确认跳转入口是否统一、域名获取是否可控，这两个点理顺了，后面会少踩很多坑。