Ответ 1
Я нашел проблему. Это с конфигурацией облачного фронта. Этот блог помог мне.
При определении происхождения я выбрал ковш S3. Мы должны войти в домен корзины S3, например telekha-test-www.s3-website.ap-south-1.amazonaws.com
Я создал облачный дистрибутив для обслуживания статического веб-сайта. S3 - исходный сервер. Теперь, если мы получим URL-адрес облачного интерфейса, он перенаправляется в местоположение S3.
d2s18t7gwlicql.cloudfront.net или test.telekha.in
В браузере он показывает https://telekha-test-www.s3.ap-south-1.amazonaws.com/index.html#/dashboard
Я ожидаю https://test.telekha.in/#/dashboard
Если я получаю доступ к https://test.telekha.in через curl, он возвращает мой index.html document
Если я получаю доступ к http://test.telekha.in через curl, он возвращает
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
Но в браузере как http, так и https перенаправляются на https://telekha-test-www.s3.ap-south-1.amazonaws.com/index.html#/
Пожалуйста, дайте мне знать, как решить эту проблему.
Я нашел проблему. Это с конфигурацией облачного фронта. Этот блог помог мне.
При определении происхождения я выбрал ковш S3. Мы должны войти в домен корзины S3, например telekha-test-www.s3-website.ap-south-1.amazonaws.com
Первое, что нужно проверить, если вы думаете, что видите это, - запустить команду curl ниже. Если он возвращает HTTP/1.1 307 Temporary Redirect
, то вы видите эту проблему.
$ curl -I https://YOUR_CF_DOMAINNAME.cloudfront.net/
HTTP/1.1 307 Temporary Redirect
Content-Type: application/xml
Content-Length: 0
Connection: keep-alive
x-amz-bucket-region: ap-southeast-2
Location: http://yourS3bucketname.s3-ap-southeast-2.amazonaws.com/
Date: Wed, 12 Jul 2017 00:20:27 GMT
Server: AmazonS3
Age: 1775
X-Cache: Hit from cloudfront
Via: 1.1 someid.cloudfront.net (CloudFront)
X-Amz-Cf-Id: someguid==
Лучшее описание, которое я нашел по этой проблеме:
S3 обновляет DNS для глобальной иерархии конечных точек REST *.s3.amazonaws.com с записью об отправке запросов в нужный регион для корзины в течение короткого времени после создания корзины, и CloudFront, кажется, полагается на это для отправки запросов вправо место. Перед завершением этого первоначального обновления S3 вернет перенаправление, а CloudFront вернет перенаправление в браузер. ~ Майкл-sqlbot
Учитывая, что эта проблема на самом деле связана с внутренним распространением DNS имени сегмента S3 (которое не является на 100% ясным, но кажется весьма вероятным), которое возникает при настройке сегмента в S3, тогда можно избежать этой проблемы, настроив общедоступный веб-сайт в S3 перед настройкой дистрибутива Cloudfront, и в соответствии с документом настройте общедоступное веб-имя S3 как источник облачного фронта, а не имя сегмента s3.
Для справки, у меня есть как имена сегментов S3, так и имена веб-сайтов S3, настроенные как источники Cloudfront, и я могу сказать, что они оба работают! (в конце концов?)
Рекомендации:
Оказывается, это просто проблема синхронизации, которая устраняется через некоторое время, если все настроено правильно. Дополнительную информацию можно найти в этой ветке форума AWS.
Текущий принятый ответ здесь и связанная статья блога предлагают включить статический веб-сайт для вашей корзины S3 и затем изменить источник CF, чтобы указать на этот статический веб-сайт. Это решение решает проблему перенаправления, но с побочным эффектом, что ваш веб-сайт теперь доступен как с использованием URL-адреса CF или вашего собственного CNAME, так и с использованием URL-адреса S3.
Чтобы подробнее остановиться на принятом ответе, эта часть в конце упомянутого поста в блоге, в частности, полезна:
Несколько дней назад я обнаружил небольшую "ошибку": при использовании URL-адресов, таких как www.example.com/about/, Amazon S3 фактически возвращает файл "index.html" внутри папки (поскольку он настроен как статическая корзина веб-сайта).).
Самое смешное, что если вы пропустите косую черту (www.example.com/about), S3 сначала проверит, существует ли объект с именем about. Если это не так, он будет считать, что about является папкой, и выдаст перенаправление 301 на about/. При использовании CloudFront это означает, что CloudFront фактически будет кешировать... перенаправление вместо самого файла! Поэтому вы должны убедиться, что все ваши URL заканчиваются косой чертой, чтобы избежать бесполезного перенаправления.
Используйте региональное доменное имя вашего сегмента S3 для настройки источника распространения CloudFront, например: {bucket-name}.s3.{region}.amazonaws.com
.
Согласно обсуждению на форумах разработчиков AWS: домен Cloudfront перенаправляет на исходный URL-адрес S3, для создания и распространения записей DNS для вновь созданных сегментов S3 требуется время. Эта проблема не видна для сегментов, созданных в регионе Восток США (Северная Вирджиния), поскольку этот регион является регионом по умолчанию (запасной вариант).
Каждый сегмент S3 имеет два доменных имени, одно глобальное и одно региональное, т.е.
{bucket-name}.s3.amazonaws.com
{bucket-name}.s3.{region}.amazonaws.com
Если вы сконфигурируете свой дистрибутив CloudFront для использования глобального доменного имени, вы, вероятно, столкнетесь с этой проблемой из-за того, что настройка DNS требует времени.
Однако вы могли бы использовать региональное доменное имя в исходной конфигурации, чтобы избежать этой проблемы DNS.
Если вы используете CloudFormation, вы можете использовать выходной атрибут RegionalDomainName
ресурса AWS::S3::Bucket
:
S3Bucket:
Type: AWS::S3::Bucket
CloudFrontDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- DomainName: !GetAtt S3Bucket.RegionalDomainName
Также я настоятельно рекомендую прочитать этот пост в блоге о будущем различных форматов S3: