Целевая группа 443 дает проверки работоспособности с этими кодами: [502] - PullRequest
Новая
       61

Целевая группа 443 дает проверки работоспособности с этими кодами: [502]

0 голосов
/ 18 марта 2020

Я хотел развернуть веб-сайт Laravel в Amazon, поэтому я сделал следующие шаги:

  • Развернул приложение Laravel с использованием Elasti c Beanstalk
  • Настроен Маршрут: 53 Экземпляр, указывающий на IP-адрес Ec2
  • Создан балансировщик нагрузки приложения с двумя слушателями, один на 80 и один на 443
  • Создал 2 целевые группы Tg80 и Tg443 и назначил слушателя соответственно

  • Обратите внимание, что Tg443 имеет действительный сертификат SSL

  • Изменена группа безопасности Ec2 на единицу балансировки нагрузки

  • Изменен экземпляр A в Route: 53 для балансировки нагрузки

** Результаты: **

  • Сайт отлично работает на порту 80 с http То же самое для проверки работоспособности, и я могу нормально зайти на сайт из любого браузера

  • Сайт возвращает [502 Bad Gateway] на https:443

  • In (после s sh до экземпляра) / var / log / httpd / error_log У меня следующая ошибка /var/www/html/.htaccess: RewriteCond: bad flag delimiters

Итак, я попробовал , по ссылке принудительное исполнение-https- laravel:

  • Чтобы настроить .htaccess в приложении laravel, как указано в ссылке, обновилось все `php artisan config: кэш, повторная проверка работоспособности, но Те же результаты

  • Я удалил .htaccess и настроил app/Providers/AppServiceProvider.php: 

    use Illuminate\Contracts\Routing\UrlGenerator; 

    public function boot(UrlGenerator $url)
    {
       if(env('ENFORCE_SSL', false)) {
         $url->forceScheme('https');
       }
    }
  • И добавил ENFORCE_SSL=true в .env, а затем php artisan config:cache, как сказано в той же ссылке это более новый способ, чем .htaccess.

Но те же результаты

Я не Не знаю, что делать net или как это исправить. Я хочу иметь доступ к сайту с помощью ssl. Пожалуйста помоги. Спасибо.

enter image description here

1 Ответ

1 голос
/ 18 марта 2020

Основываясь на комментариях, проблема заключалась в том, что проверки работоспособности были настроены на использование HTTPS между ALB и EC2. Однако, поскольку ALB завершает SSL-соединения, весь трафик c между ALB и EC2 выполняется по протоколу HTTP, а не по HTTPS.

Следовательно, решение проблемы неработающих проверок работоспособности состояло в том, чтобы использовать для них HTTP, а не HTTPS. .

...