首页 > 解决方案 > CloudFront、Application LoadBalancer、EC2 获得重定向 301

问题描述

我在尝试添加到现有结构的 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 存储桶。不确定这是否只是服务器名称。

任何建议将被认真考虑。

标签: amazon-web-servicesnginxamazon-ec2amazon-cloudfrontaws-application-load-balancer

解决方案


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

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

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


推荐阅读