CloudFront、应用程序负载均衡器、EC2 获取重定向 301

Posted

技术标签:

【中文标题】CloudFront、应用程序负载均衡器、EC2 获取重定向 301【英文标题】:CloudFront, Application LoadBalancer, EC2 Getting Redirect 301 【发布时间】:2021-04-14 21:59:38 【问题描述】:

我在尝试添加到现有结构的 CloudFront 时遇到问题,不是为了缓存的好处,而是为了保护。 后端具有访问数据库并将 json 响应回显给调用者的 php 文件。 所以后端提供了 100% 的动态内容。 (无静态内容)

现在有效的是

Application Load Balancer (HTTP:80 redirect -> HTTPS:443, HTTPS:443) with its own ACM public cert -> EC2 (nginx, HTTP:80)

我将负载平衡器 DNS 名称映射到自定义名称并在 Route 53 中注册。 而且我可以毫无问题地访问我的 php 文件。

什么是行不通的

CloudFront (HTTP:80 -> HTTPS:443) -> Application Load Balancer(same config) -> EC2(same config)

CloudFront 设置

Custom DNS.
AWS public SSL in (N. Virginia) Region.
HTTP -> HTTPS redirect.
Cache Policy is set to Managed-CachingDisabled.
Origin Request Policy is set to Manager-AllViewer.

应用程序负载均衡器设置

Located in us-west-2 region.
Availability Zone us-west-2b, us-west-2d
Redirect HTTP -> HTTPS
HTTPS -> Forward to Target group (HTTP:80)
ELBSecurityPolicy-TLS-1-2-2017-01

EC2 实例设置

Located in us-west-2 region.
server 
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com;
    server_tokens off;
    root /home/forge/example.com/public;

    # FORGE SSL (DO NOT REMOVE!)
    # ssl_certificate;
    # ssl_certificate_key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS_AES_256_GCM_SHA384:TLS-AES-256-GCM-SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparams.pem;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    # FORGE CONFIG (DO NOT REMOVE!)
    include forge-conf/example.com/server/*;

    location / 
        try_files $uri $uri/ /index.php?$query_string;
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host                 $host;
        proxy_set_header   X-Forwarded-HTTPS    on;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_redirect off;
    

    location = /favicon.ico  access_log off; log_not_found off; 
    location = /robots.txt   access_log off; log_not_found off; 

    access_log off;
    error_log  /var/log/nginx/example.com-error.log error;

    error_page 404 /index.php;

    location ~ \.php$ 
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    

    location ~ /\.(?!well-known).* 
        deny all;
    

结果是响应码 301。

* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
 [5 bytes data]
* Using Stream ID: 1 (easy handle 0xe20900)
 [5 bytes data]
> GET /index.php HTTP/2
> user-agent: curl/7.67.0
> accept: */*
>
 [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
 [5 bytes data]
< HTTP/2 301
< content-type: application/xml
< content-length: 0
< date: Sat, 09 Jan 2021 10:34:01 GMT
< server: AmazonS3
< location: /index.php/
< x-cache: Miss from cloudfront
< via: 1.1 e61b74b41588d9216f1bb35848394554.cloudfront.net (CloudFront)
< x-amz-cf-pop: SFO20-C1
< x-amz-cf-id: krUsSzIvjDtNANyPun9uipkHOhRQ70HfUgo4yXDqgzwK953hkcJO_g==
<
 [0 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host example.com left intact

在上面的 curl 输出中,我看到了 server: AmazonS3,但我没有使用 S3 存储桶。不确定这是否只是服务器名称。

我们将不胜感激。

【问题讨论】:

为 ALB 和 CF 设置的域(足够示例)和 ssl 证书是什么。您是否为 ALB 和 CF 使用相同的域和 ssl? 我使用不同的域和 SSL。 ALB:alb.myserver.com(SSL 证书:alb.myserver.com) CF:api.myserver.com(SSL 证书:api.myserver.com) 【参考方案1】:

原来我之前在俄亥俄州使用相同的域名错误地创建了一个放大应用程序。 在联系支持人员之前,我不知道这样的应用程序在不同地区的幕后运行。 更改了右上角的区域,它终于出现了。 我希望他们有一个仪表板,显示在同一帐户下运行的所有应用程序和实例,以便更容易发现和控制。 在逐个浏览每个区域后,我注意到我还运行了一些未使用的资源,这些资源肯定是我在不久前尝试学习 AWS 时创建的。

所以在不知道这个 Amplify 应用程序的情况下保留了我尝试使用的域名, 当我输入域时,CloudFront 设置中的 CNAME 字段引发了异常。 当我试图解决这个问题时,我添加了一个 Route 53 CNAME 来强制使用导致重定向的域名。

移除应用,移除 Route 53 CNAME 记录,在 CloudFront 的 CNAMEs 字段中添加域,之后一切顺利。

【讨论】:

以上是关于CloudFront、应用程序负载均衡器、EC2 获取重定向 301的主要内容,如果未能解决你的问题,请参考以下文章

AWS 将 EC2 替换为 CloudFront

如何使用 EC2 网站设置 Cloudfront

用于 PHP 托管的 AWS CloudFront

从 http 重定向到 https 时,cloudfront 域被应用程序负载均衡器 dns 名称替换

Lambda@edge 实现负载均衡器功能

Amazon CloudFront 未针对未更改的静态内容始终返回 304(未修改)?