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

HaProxy случайным образом возвращает 503 для статических файлов, когда серверы доступны

HaProxy случайным образом возвращает 503, хотя серверные серверы определенно доступны. Серверная часть правильно обслуживает файлы, поскольку это видно из журнала доступа. всегда возвращаю 200 или 304. Я чешу в затылке, почему это происходит. Самое странное в том, что это только происходит в этом файле css!

Пример 503 сообщения журнала:

3 октября 17:26:24 haproxy0-1 haproxy [2313]: xxxx: 53265 [03 / Oct / 2018: 17: 26: 24.187] https-in ~ appName / apps-1.prod.companyName.com 0/0 / -1 / -1 / 1 503213 - - CC-- 22/22/16/8/0 0/0 {|} "GET /appName/resources/css/appName.css HTTP / 1.1"

Конфигурация HaProxy:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!AES256
    ssl-default-bind-options force-tlsv12
    tune.ssl.default-dh-param 2048
    lua-load /etc/haproxy/cors.lua

defaults
    log global
    mode http
    option forwardfor
    option httplog
    option dontlognull
    option redispatch
    retries 3
    timeout http-request 20000
    timeout queue 20000
    timeout connect 20000
    timeout client 20000
    timeout server 20000
    timeout http-keep-alive 20000
    timeout check 500
    maxconn 3000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend https-in
    bind :443 ssl crt /etc/ssl/private/prod.companyName.com.pem alpn h2,http/1.1
    capture request header origin len 128
    capture request header access-control-request-headers len 128
    http-response set-header Access-Control-Allow-Origin %[capture.req.hdr(0)] if !METH_OPTIONS { capture.req.hdr(0) -m reg -f /etc/haproxy/cors-origins.lst }
    http-request use-service lua.cors-response if METH_OPTIONS { capture.req.hdr(0) -m reg -f /etc/haproxy/cors-origins.lst }
    acl acl_appName path_beg /appName if !METH_OPTIONS
    use_backend appName if acl_appName
    default_backend no-match

backend appName
    reqadd X-Forwarded-Proto:\ https
    balance leastconn
    option httpchk GET /appName/haproxy.jsp HTTP/1.0
    server apps-1.prod.companyName.com apps-1.prod.companyName.com:8443 check ssl verify required ca-file /usr/local/share/ca-certificates/companyName-CA.crt
    server apps-3.prod.companyName.com apps-3.prod.companyName.com:8443 check ssl verify required ca-file /usr/local/share/ca-certificates/companyName-CA.crt

backend no-match
    http-request deny deny_status 404

listen stats
    bind localhost:9000
    mode http
    stats enable
    stats realm Haproxy\ Statistics
    stats uri /stats
    #stats admin if TRUE

Спасибо за любую помощь!

Вероятно, это запросы от Firefox с включенным RCWN ("Race Cache With Network"):

«CC--» показывает, что клиент прерван до того, как соединение могло быть установлено с внутренним сервером, что происходит, когда Firefox отправляет HTTP-запрос на haproxy, а затем немедленно закрывает соединение (потому что он нашел ответ в своем кеше).

Fire Fox nsHttpChannel.cpp:

// We will attempt to race the network vs the cache if we've found
// this entry in the cache index, and it has appropriate attributes
// (doesn't have alt-data, and has a small size)

Смотрите также о: сети # rcwn (в Firefox)