Назад | Перейти на главную страницу

Varnish Error 503 Не удалось получить серверную часть только на домашней странице (Magento 2.3.5-p1)

Я немного смущен, на самом деле очень смущен, не касаясь лака и его настройки. В настоящее время я использую Magento 2 на Nginx / PHP-FPM и использую только SSL, т.е. я перенаправляю пользователя с: 80 на: 443, поскольку я хочу, чтобы они получали доступ только через SSL. Также прямо сейчас Magento 2 настроен для cache / page_cache и сеанса в Redis (настройка на локальном сервере). Однако я хочу использовать лак для кеширования страниц.

1) Для этого хочу установить лак через докер используя данное изображение. Я экспортировал файл default.vcl, созданный администратором Magento, и поместил его в /etc/varnish/default.vcl и использовал следующие команды:

docker run -e VARNISH_CONFIG_FILE = / etc / varnish / default.vcl
- перезапуск, если не остановлен
-v /etc/varnish/default.vcl:/etc/varnish/default.vcl
-Pit --name = лак-альпийский тиагофигейро / лак-альпийский-докер

в default.vcl файл, который я настроил .port = 6085, однако Varnish начинает слушать порт 32768 вместо. Похоже, он не читает мои default.vcl файл.

2. В настоящее время Nginx слушает 80 и 443, и если я нанесу лак 80:80 это дает мне ошибку Address already in use в журналах докеров. Я хотел нанести лак на port 6085 и пусть magento выполняет кеширование страниц на этом порту. Но из того, что я исследовал, похоже, что мне придется запустить лак на порту 80, а затем мои веб-сайты, чтобы прослушивать другой порт и перенаправлять трафик с порта 80 на порт веб-сайта (прокси). Я прав? Таким образом, веб-сервер (Nginx) фактически будет работать на порту, например. 8080 для HTTP и 8082 для HTTPS, и эти порты будут открыты внутри (localhost) только для публики. Но как тогда лак будет общаться на ПОРТ 443?

Возможно ли, что я установлю лак на отдельном сервере? Или лак должен быть установлен на том же сервере, что и веб-сервер.

Если я могу установить лак на отдельный сервер, то как я могу заставить его работать с nginx (на другом сервере).

Заглавие: Изменен заголовок, чтобы отразить обновленную проблему, указанную ниже.

ОБНОВИТЬ:

Хорошо, я смог заставить лак работать, но он выдает ошибку 503 Backend fetch fetch on www.domain.com (домашняя страница), но отлично работает с любой подпапкой или страницами, например www.domain.com/index.php.

Лаковые журналы для /:

 << Request  >> 33
-   Begin          req 32 rxreq
-   Timestamp      Start: 1594304417.447698 0.000000 0.000000
-   Timestamp      Req: 1594304417.447698 0.000000 0.000000
-   VCL_use        boot
-   ReqStart       1.1.0.1 47738 a0
-   ReqMethod      GET
-   ReqURL         /
-   ReqProtocol    HTTP/1.0
-   ReqHeader      Host: www.domain.com
-   ReqHeader      X-Real-IP: 162.158.155.131
-   ReqHeader      X-Forwarded-For: x.x.x.x, 162.158.155.131
-   ReqHeader      X-Forwarded-Proto: https
-   ReqHeader      X-Forwarded-Port: 443
-   ReqHeader      Connection: close
-   ReqHeader      Accept-Encoding: gzip
-   ReqHeader      CF-IPCountry: 
-   ReqHeader      CF-RAY: 5b02af62b8a4ca78-
-   ReqHeader      CF-Visitor: {"scheme":"https"}
-   ReqHeader      accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-   ReqHeader      user-agent: 
-   ReqHeader      accept-language: en-us
-   ReqHeader      cookie: PHPSESSID=; 
-   ReqHeader      CF-Request-ID: 03d58bf1af0c200000001
-   ReqHeader      CF-Connecting-IP: x.x.x.x
-   ReqHeader      CDN-Loop: cloudflare
-   ReqUnset       X-Forwarded-For: x.x.x.x, 162.158.155.131
-   ReqHeader      X-Forwarded-For: x.x.x.x, 162.158.155.131, 1.1.0.1
-   VCL_call       RECV
-   ReqHeader      grace: none
-   ReqURL         /
-   ReqUnset       Accept-Encoding: gzip
-   ReqHeader      Accept-Encoding: gzip
-   VCL_return     hash
-   VCL_call       HASH
-   VCL_return     lookup
-   VCL_call       MISS
-   VCL_return     fetch
-   Link           bereq 34 fetch
-   Timestamp      Fetch: 1594304417.448049 0.000351 0.000351
-   RespProtocol   HTTP/1.1
-   RespStatus     503
-   RespReason     Backend fetch failed
-   RespHeader     Date: Thu, 09 Jul 2020 14:20:17 GMT
-   RespHeader     Server: Varnish
-   RespHeader     content-type: text/html; charset=utf-8
-   RespHeader     Retry-After: 5
-   RespHeader     X-Varnish: 33
-   RespHeader     Age: 0
-   RespHeader     Via: 1.1 varnish (Varnish/6.4)
-   VCL_call       DELIVER
-   RespUnset      Age: 0
-   RespHeader     Pragma: no-cache
-   RespHeader     Expires: -1
-   RespHeader     Cache-Control: no-store, no-cache, must-revalidate, max-age=0
-   RespUnset      Server: Varnish
-   RespUnset      X-Varnish: 33
-   RespUnset      Via: 1.1 varnish (Varnish/6.4)
-   VCL_return     deliver
-   Timestamp      Process: 1594304417.448084 0.000386 0.000035
-   Filters
-   RespHeader     Content-Length: 279
-   RespHeader     Connection: close
-   Timestamp      Resp: 1594304417.448153 0.000455 0.000068
-   ReqAcct        1428 0 1428 264 279 543
-   End

*   << Session  >> 32
-   Begin          sess 0 HTTP/1
-   SessOpen       1.1.0.1 47738 a0 1.1.0.4 80 1594304417.447629 23
-   Link           req 33 rxreq
-   SessClose      REQ_CLOSE 0.001
-   End

Я уже добавил следующие параметры в лак, но ошибка все еще существует.

-p http_resp_hdr_len=65536
-p http_resp_size=98304

ОБНОВИТЬ: Это мои файлы конфигурации nginx и varnish.

nginx.conf: https://pastebin.com/raw/tQ9wAmEP

default.vcl: https://pastebin.com/raw/JmE5fncy

Согласно текущей конфигурации, запрос http: // domain.com/ перехватывается Varnish. Varnish передает этот запрос на localhost: 8080, где его слушает Nginx. Nginx (который не знает о domain.com, поэтому используется конфигурация сервера по умолчанию, т.е. первая) отвечает перенаправлением на https: // www.example.com. Когда браузер учитывает это, второй запрос обрабатывается самим Nginx, который proxy_ передает этот запрос на http: // 127.0.0.1:80, где Varnish прослушивает. Перезагрузите с самого начала.