Cloudfront custom-origin distribution zwraca błąd 502 " żądanie nie może zostać spełnione."dla niektórych adresów URL

[1]}mamy dystrybucję Cloudfront z niestandardowym origin, która działa dobrze przez dość długi czas, obsługując zasoby statyczne dla jednej z naszych witryn. Właśnie dziś rano zauważyliśmy, że nasze logo wyświetla się jako zepsuty link.

Po dalszym dochodzeniu, Cloudfront zwraca dziwny komunikat o błędzie, którego nigdy wcześniej nie widziałem dla url, o którym mowa :

Błąd

Wniosek nie mógł zostać spełniony.



Wygenerowane przez cloudfront (CloudFront)

Kilka innych adresów URL Cloudfront z tej dystrybucji zwraca ten sam błąd, ale inne (znowu z tej samej dystrybucji) działają poprawnie. Nie widzę wzoru na to, co działa, a co nie.

Niektóre inne punkty danych:

  • adresy URL Origin działają poprawnie. O ile mi wiadomo, nie było żadnej przerwy w służbie.
  • unieważniłem adres URL logo specjalnie, bez skutku.
  • unieważniłem główny adres URL dystrybucji, bez skutku.
Wiesz, co tu się dzieje? Nigdy wcześniej nie widziałem, żeby Cloudfront tak robił.

UPDATE:

Oto odpowiedź Verbatim HTTP z Cloudfront:

$ 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>
Author: Eddie Loeffen, 0000-00-00

1 answers

Ostatnio miałem podobny problem, który okazał się być spowodowany przez ssl_ciphers, którego używałem.

Od http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html,

"CloudFront przekazuje żądania HTTPS do serwera origin za pomocą protokołów SSLv3 lub TLSv1 oraz szyfrów AES128-SHA1 lub RC4-MD5. Jeśli serwer origin nie obsługuje szyfrów AES128-SHA1 lub RC4-MD5, CloudFront nie może ustanowić protokołu SSL połączenie z Twoim pochodzeniem. "

[1]}musiałem zmienić moje konfg nginx, aby dodać AES128-SHA ( deprecated RC4:HIGH ) do ssl_ciphers, aby naprawić błąd 302. Mam nadzieję, że to pomoże. Wkleiłem linię z mojego ssl.conf
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
 29
Author: dminer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-29 03:46:18