Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
225 views
in Technique[技术] by (71.8m points)

amazon web services - CloudFront, Application LoadBalancer, EC2 Getting Redirect 301

I'm having an issue with the CloudFront I'm trying to add to the existing structure not for benefits of caching but solely for protections. The backend has php files which access database and echo json responses back to callers. So the backend provides 100% dynamic contents. (no static contents)

What's working right now is

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

I mapped the load balancer DNS name to a custom name and registered in Route 53. And I can access my php files without any issue.

What does not work is

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

CloudFront settings

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.

Application Load Balancer settings

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 instance settings

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;
    }
}

The result is response code 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

In the curl output above, I see server: AmazonS3 but I don't use S3 buckets. Not sure if that's just a server name.

Any advice will be appreciated.

question from:https://stackoverflow.com/questions/65641798/cloudfront-application-loadbalancer-ec2-getting-redirect-301

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

Turned out I had an amplify app created by mistake in Ohio region a while back using the same domain name. I had no clue such app was running behind the scene in different regions until I contacted the support. Changed the region at the right upper corner and it finally showed up. I wish they had a dashboard which shows all apps and instances running under the same account to make things easier to spot and control. After going through each region one by one, I noticed I had some unused resources running as well which I must have created when trying to learn AWS a while back.

So without knowing this Amplify app reserved the domain name that I was trying to use, CNAMEs field in CloudFront settings was throwing an exception when I typed in the domain. As I was trying to workaround the issue, I added a Route 53 CNAME to forcefully use the domain name which has caused redirect.

Removed the app, removed Route 53 CNAME record, added the domain in CNAMEs field in CloudFront, everything went smooth afterwards.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...