为何Guzzle请求CloudFront接口返回403，Curl/Postman/浏览器访问正常

• 对接CloudFront托管的API接口时，使用Guzzle发起的固定参数请求始终返回403权限错误
• 完全相同的请求参数，切换为PHP Curl、Postman、浏览器发起时均可正常获得服务端响应
• 当前项目中Guzzle客户端的核心实现代码如下：

/**
 * @return void
 */
public function __construct()
{
    $this->client = new Client([
        'base_uri' => env('API_HOST'),
        'headers'  => [
            'Accept' => 'application/json',
            'Content-Type' => 'application/json',
        ],
        'timeout' => 30,
        'debug' => true,
    ]);
}

/**
 * @param string $method
 * @param string $url
 * @param array $body
 * @param bool $isMultipart
 *
 * @return ResponseInterface
 */
private function request(string $method, string $url, array $body = [], bool $isMultipart = false): ResponseInterface
{
    if ($isMultipart) {
        $params['multipart'] = [$body];
    } else {
        $params['json'] = $body;
    }

    $url = $this->appedAuthTokensToUrl($url);

    return $this->client->request($method, $url, $params);
}

• 可通过Guzzle自带的debug日志，核对客户端实际发送的全量请求报文，和可正常响应的请求逐字段比对定位差异

• UA头拦截（这类场景最高发）：当前Guzzle配置未显式指定User-Agent头，会自动使用默认的GuzzleHttp/当前版本号作为请求标识，多数接入WAF的CloudFront分发会将这类请求判定为异常爬虫直接返回403。修复时只需在客户端初始化的headers配置块中，手动设置和PHP Curl/Postman完全一致的UA值即可
• 请求头特征拦截：Guzzle默认会自动附加Accept-Encoding: gzip, deflate请求头，部分WAF规则会对携带这类默认Guzzle特征头的请求触发拦截。可在配置中显式指定和正常客户端一致的Accept-Encoding值，或关闭Guzzle的自动内容编码附加逻辑
• TLS握手指纹拦截：CloudFront的WAF会基于TLS握手特征识别非浏览器请求，老版本Guzzle依赖的curl扩展会协商和常规浏览器/原生curl不同的TLS握手参数，会被判定为异常请求拦截。可升级服务器端curl扩展版本，或对齐正常客户端的TLS协商参数
• 报文格式偏差：Guzzle默认会自动计算Content-Length、处理请求重定向，部分场景下会和手动传入的请求参数冲突，导致服务端校验失败。可通过debug日志打印实际发送的完整报文，和Postman的正常请求报文逐字段对比，修正参数格式差异
• 鉴权参数异常：需检查appedAuthTokensToUrl方法的实现，确认拼接鉴权参数后的URL是否存在路径拼接错误、参数转义异常、签名计算偏差的问题，这类异常在CloudFront的签名校验逻辑下会直接返回403，不会返回明确的参数错误提示

内容的提问来源于stack exchange，提问作者Allan Santos