Cloudfront custom-origin 배포가 502 "오류 요청을받을 수 없습니다."를 반환합니다. 일부 URL의 경우
우리 사이트 중 하나에 정적 자산을 제공하면서 오랫동안 잘 작동하는 사용자 지정 오리진이있는 Cloudfront 배포판이 있습니다. 바로 오늘 아침에 로고가 깨진 링크로 표시되는 것을 발견했습니다.
추가 조사에서 Cloudfront는 문제 의 URL에 대해 이전에 본 적이없는 이상한 오류 메시지를 반환합니다 .
오류
요청을받을 수 없습니다.
CloudFront에서 생성 (CloudFront)
이 배포의 여러 다른 Cloudfront URL이 동일한 오류를 반환하지만 다른 (다시 동일한 배포의) URL이 제대로 작동합니다. 작동하는 것과 동일한 것에 대한 패턴이 있습니다.
기타 데이터 포인트 :
- 기원 URL은 잘 작동합니다. 내가 아는 한, 최근 서비스 중단은 없었습니다.
- 특별히 로고 URL을 무효화했습니다.
- 배포의 루트 URL을 무효화했습니다.
여기서 무슨 일이 일어나는지 아십니까? Cloudfront 가이 작업을 수행하는 것을 본 적이 없습니다.
최신 정보 :
Cloudfront의 약어 HTTP 응답은 다음과 가능합니다.
$ http GET https://d2yu7foswg1yra.cloudfront.net/static/img/crossway_logo.png
HTTP/1.1 502 Bad Gateway
Age: 213
Connection: keep-alive
Content-Length: 472
Content-Type: text/html
Date: Wed, 18 Dec 2013 17:57:46 GMT
Server: CloudFront
Via: 1.1 f319e8962c0268d31d3828d4b9d41f98.cloudfront.net (CloudFront)
X-Amz-Cf-Id: H_HGBG3sTOqEomHzHubi8ruLbGXe2MRyVhGBn4apM0y_LjQa_9W2Jg==
X-Cache: Error from cloudfront
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
</BODY></HTML>
<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated by cloudfront (CloudFront)
</ADDRESS>
</BODY></HTML>
최근에 내가 사용하고 ssl_ciphers로 인해 문제가 발생했습니다.
"CloudFront는 SSLv3 또는 TLSv1 프로토콜과 AES128-SHA1 또는 RC4-MD5 암호를 사용하여 HTTPS 요청을 오리진 서버로 전달합니다. 오리진 서버가 AES128-SHA1 또는 RC4-MD5 암호를 지원하지 않는 경우 CloudFront는 SSL 연결에 접근합니다. 당신의 기원에. "
302 오류를 수정하기 위해 ssl_ciphers에 AES128-SHA (더 이상 사용하지 않는 RC4 : HIGH)를 추가로 nginx 구성을 변경해야합니다. 이게 도움이 되길 계속. 내 ssl.conf에서 줄을 넣었습니다.
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
오늘 Amazon Cloudfront 에서이 오류가 발생했습니다. 내가 현장 cname (예 : cdn.example.com)이 "alternate cnames"의 배포 설정에 추가되지 않은 현상 때문에 cdn.example.com 만 내 사이트 / 호스팅의 cloudfront 도메인으로 전달합니다. Amazon CloudFront 패널에도 추가해야합니다.
내 대답을 찾아 여기에 추가하여 David (및 다른 사람들)에게 도움이 될 수 있습니다.
내 원본 서버 (예 : www.example.com)에 HTTP를 HTTPS로 변경하기 위해 301 리디렉션 설정이있는 오류가 있습니다.
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/images/Foo_01.jpg
그러나 내 Origin Protocol Policy는 HTTP 전용으로 설정되었습니다. 이로 인해 CloudFront에서 내 파일을 찾지 못했지만 502 오류가 발생했습니다. 또한 301 리디렉션을 오류 오류에 작동하지 사고 기 때문에 5 분 동안 502를 캐시하고 있습니다.
도움이 되셨기를 바랍니다.
우리의 경우 모든 것이 괜찮아 보였지만 그것을 알아내는 데 거의 하루가 걸렸습니다.
TLDR : 인증서 경로를 확인하여 루트 인증서가 올바른지 확인하십시오. COMODO 인증서의 경우 "USERTrust"라고 표시되고 "AddTrust External CA Root"에서 발급되어야합니다. "COMODO RSA 인증 기관"에서 발행 한 "COMODO"가 아닙니다.
CloudFront 문서에서 : http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html
오리진 서버가 오류 인증서 또는 자체 서명 서버가 잘못된 인증서를 반환하거나 오리진 서버가 잘못된 인증서를 반환하거나 반환하는 경우 CloudFront는 TCP 연결을 삭제하고 HTTP 코드 502를 반환하고 X-Cache 헤더를 오류로 설정합니다. cloudfront에서.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption에 따라 올바른 암호를 활성화했습니다.
우리의 인증서는 Google, Firefox 및 ssl-checker에 따라 유효했습니다 : https://www.sslshopper.com/ssl-checker.html
그러나 SSL 검사기 체인의 마지막 인증서는 "COMODO RSA 인증 기관"에서 발급 한 "COMODO RSA 도메인 유효성 검사 보안 서버 CA"였습니다.
CloudFront는 "COMODO RSA 인증 기관"에 대한 인증서를 보유하지 않고있는 보이며 오리진 서버에서 제공하는 한 인증서가 자체 서명 된 것으로 생각합니다.
이것이 갑자기 멈추기 전에 오랫동안 작동했습니다. 무슨 일이 있었는지 방금 1 년 동안 인증서를 업데이트했지만 가져 오는 동안 이전 모든 인증서의 인증서 경로에서 조치 변경 . 모두 "COMODO RSA 인증 기관"을 참조하기 시작했지만, 이전에는 더 길어야 루트는 "AddTrust External CA Root"였습니다.
이 때문에 이전 인증서로 다시 전환해도 cloudfront 문제가 해결되지 않습니다.
AddTrust를 참조하지 않는 "COMODO RSA 인증 기관"이라는 추가 인증서를 삭제해야합니다. 이렇게하면 모든 웹 사이트 인증서의 경로가 다시 AddTrust / USERTrust를 가리 키도록 업데이트되었습니다. 또한 경로에서 잘못된 루트 인증서를 "세부 정보"-> "속성 편집"을 클릭 한 다음 그런 방식으로 비활성화 수도 있습니다. 이 즉시 경로를 업데이트했습니다. "개인"및 "신뢰할 수있는 루트 인증 기관"에있는 여러 인증서 사본을 삭제할 수 있습니다.
마지막으로 새로운 인증서 체인을 제공하기 위해 IIS에서 인증서를 다시 선택했습니다.
그 후 ssl-checker는 "AddTrust External CA Root"를 도메인 세 번째 인증서를 체인에 표시하기 시작했습니다.
마지막으로 CloudFront는 오리진 서버의 인증서와 체인을 보유 수있는 수락했습니다. CDN이 다시 작동하기 시작했습니다!
앞으로 올바른 인증서가 발생하지 않도록 반드시 새로 생성 된 인증서를 보내야합니다. 즉, "COMODO RSA Certification Authroity"에서 발급 한 인증서 "COMODO RSA Certification Authroity"(2038 년 종료)를 불신하거나 삭제해야합니다. ). 이 인증서가 기본적으로 설치되는 Windows 시스템에만 설치되는 것입니다.
방금이 문제를 해결하는 과정을 거쳤으며 제 경우에는 실제로 리디렉션과 관련이 있었지만 CloudFront Origin 또는 Behavior의 잘못된 설정과는 관련이 없습니다. 이는 오리진 서버가 여전히 클라우드 프론트 URL에 대해 설정 한 것이 아니라 오리진 URL로 리디렉션하는 경우에 발생 합니다 . 구성 변경을 잊은 경우 매우 일반적입니다. 예를 들어, 출처가 www.yoursiteorigin.com 인 클라우드 프론트 배포에 www.yoursite.com CNAME이 있다고 가정 해 보겠습니다. 분명히 사람들은 www.yoursite.com에 올 것입니다. 그러나 코드가 www.yoursiteorigin.com의 페이지로 리디렉션을 시도하면이 오류가 발생합니다.
나에게 내 오리진은 여전히 내 Cloudfront URL이 아닌 내 오리진 URL로 http-> https 리디렉션을 수행하고있었습니다.
제 경우에는 잘못된 SSL 인증서가 있었기 때문입니다. 문제는 스테이징 박스에 있었고 우리는 그것에 대해서도 제품 인증서를 사용합니다. 이 구성으로 지난 몇 년 동안 작동했지만 갑자기이 오류가 발생하기 시작했습니다. 이상한.
다른 사용자가이 오류를 수신하는 경우 SSL 인증서가 유효한지 확인하십시오. 디버깅을 돕기 위해 AWS CloudFront 배포 인터페이스를 통해 s3에 대한 로깅을 활성화 할 수 있습니다.
또한 문제에 대한 Amazon 문서는 http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html 에서 참조 할 수 있습니다.
한 가지 더 가능한 솔루션 : HTTP를 통해 사이트와 Cloudfront 자산을 제공하는 스테이징 서버가 있습니다. 내 오리진을 "HTTP 전용"대신 "매치 뷰어"로 설정했습니다. 또한 모든 http://*.cloudfront.netURL을 https://*버전으로 리디렉션하는 HTTPS Everywhere 확장을 사용합니다 . 스테이징 서버는 SSL을 통해 사용할 수없고 Cloudfront가 뷰어와 일치했기 때문에 자산을 찾을 수 https://example.com없었고 대신 502 개를 캐시했습니다.
우리의 경우 오리진 서버에서 PCI-DSS 준수를 위해 SSL3, TLS1.0 및 TLS1.1에 대한 지원을 중단했습니다. 그러나 CloudFront 오리진 서버 구성에서 TLS 1.1+에 대한 지원을 수동으로 추가해야합니다 . AWS 콘솔은 클라이언트 -CF SSL 설정을 표시하지만 드릴 다운 할 때까지 CF- 오리진 설정을 쉽게 표시하지 않습니다. 문제를 해결하려면 CloudFront의 AWS 콘솔에서 다음을 수행하십시오.
- 배포를 클릭합니다.
- 배포판을 선택하십시오.
- ORIGINS 탭을 클릭합니다.
- 원본 서버를 선택하십시오.
- 편집을 클릭하십시오.
- 오리진이 "Origin SSL Protocols"에서 지원하는 모든 프로토콜을 선택하십시오.
프록시 사용을 중단 한 후 저절로 해결되는이 문제가 발생했습니다. CloudFront가 일부 IP를 블랙리스트에 올릴 수 있습니다.
내 인증서를 연결하여 유효한 인증서 체인을 생성하여이 문제를 해결했습니다 (GoDaddy 표준 SSL + Nginx 사용).
http://nginx.org/en/docs/http/configuring_https_servers.html#chains
체인을 생성하려면 :
cat 123456789.crt gd_bundle-g2-g1.crt > my.domain.com.chained.crt
그때:
ssl_certificate /etc/nginx/ssl/my.domain.com.chained.crt;
ssl_certificate_key /etc/nginx/ssl/my.domain.com.key;
도움이 되었기를 바랍니다.
필자의 경우 nginx를 API 게이트웨이 URL의 역방향 프록시로 사용합니다. 같은 오류가 발생했습니다.
Nginx 구성에 다음 두 줄을 추가하면 문제가 해결되었습니다.
proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com";
proxy_ssl_server_name on;
출처 : API Gateway에 대한 API 호출을 위해 nginx에서 proxy_pass 설정
제 경우 문제는 제가 Amazon의 Cloudflare와 Cloudfront의 Cloudfront를 함께 사용하고 있었고 Cloudfront는 제가 Cloudflare를 제공 한 설정을 좋아하지 않았다는 것입니다.
보다 구체적으로 Cloudflare의 암호화 설정에서 Cloudfront의 배포에 대해 TLS 1.2 통신 설정을 활성화하지 않고 "최소 TLS 설정"을 1.2로 설정했습니다. 이것은 Cloudfront가 Cloudflare 보호 서버에 연결을 시도 할 때 502 Bad Gateway 오류를 선언하도록하기에 충분했습니다.
이 문제를 해결하려면 해당 Cloudfront 배포에 대한 Origin 설정에서 SSLv3 지원을 비활성화하고 해당 원본 서버에 대해 지원되는 프로토콜로 TLS 1.2를 활성화해야했습니다.
이 문제를 디버깅하기 위해 저는 curl의 명령 줄 버전을 사용하여 CDN에서 이미지를 요청했을 때 Cloudfront가 실제로 어떤 결과를 반환하는지 확인했으며, Openssl의 명령 줄 버전을 사용하여 Cloudflare가 정확히 어떤 프로토콜인지 확인했습니다. 제공합니다 (TLS 1.0을 제공하지 않았습니다).
tl : dr; 모든 것이 TLS 1.2를 수락하고 요청하는지 확인하거나 읽을 때까지 모든 사람이 사용하는 최신 TLS를 확인합니다.
'ProgramingTip' 카테고리의 다른 글
| Python : 목록의 모든 항목이 동일한 항목인지 확인 (0) | 2020.11.19 |
|---|---|
| `database.yml` 파일 내의 환경 변수에 액세스하지 못함 (0) | 2020.11.19 |
| 오류 : 각도 입력의 [ng : areq] (0) | 2020.11.19 |
| any () 함수의 반대 (0) | 2020.11.19 |
| imdb.load_data () 함수에 대해 'allow_pickle = False'일 때 개체 배열을로드 할 수 없음을 수정하는 방법은 무엇입니까? (0) | 2020.11.19 |