Varnish 503 nothing in Apache log - apache

We are getting random 503 responses from Varnish and when looking deeper in varnishlog we see that the backend server (Apache) is reported as a 503 but there is nothing in the apache access log.
How can we trace the cause of this issue?
From varnishlog
* << Request >> 42221068
- Begin req 42221065 rxreq
- Timestamp Start: 1553163507.132639 0.000000 0.000000
- Timestamp Req: 1553163507.132639 0.000000 0.000000
- ReqStart 172.31.19.159 14390
- ReqMethod POST
- ReqURL /path/to/request
- ReqProtocol HTTP/1.1
- ReqHeader X-Forwarded-For: 62.103.214.39
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-Port: 443
- ReqHeader Host: server.com
- ReqHeader X-Amzn-Trace-Id: Root=1-5c9364f3-26a603e3ce2f87d9923ed27e
- ReqHeader Content-Length: 53
- ReqHeader Accept: application/json
- ReqHeader Authorization: Bearer xxx
- ReqHeader Content-Type: application/json; charset=utf-8
- ReqHeader Cookie: PHPSESSID=o1f3010cuch8iu055stl6q1s03
- ReqUnset X-Forwarded-For: 62.103.214.39
- ReqHeader X-Forwarded-For: 62.103.214.39, 172.31.19.159
- VCL_call RECV
- VCL_return pass
- VCL_call HASH
- VCL_return lookup
- VCL_call PASS
- VCL_return fetch
- Link bereq 42221069 pass
- Storage malloc Transient
- Timestamp ReqBody: 1553163507.952175 0.819536 0.819536
- Timestamp Fetch: 1553163507.952297 0.819659 0.000123
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Thu, 21 Mar 2019 10:18:27 GMT
- RespHeader Server: Varnish
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 42221068
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish (Varnish/5.2)
- VCL_call DELIVER
- RespUnset Age: 0
- RespUnset Server: Varnish
- RespUnset X-Varnish: 42221068
- RespUnset Via: 1.1 varnish (Varnish/5.2)
- VCL_return deliver
- Timestamp Process: 1553163507.952322 0.819683 0.000024
- RespHeader Content-Length: 285
- RespHeader Connection: keep-alive
- Timestamp Resp: 1553163507.952341 0.819703 0.000020
- ReqAcct 415 53 468 194 285 479
- End
** << BeReq >> 42221069
-- Begin bereq 42221068 pass
-- Timestamp Start: 1553163507.132720 0.000000 0.000000
-- BereqMethod POST
-- BereqURL /path/to/request
-- BereqProtocol HTTP/1.1
-- BereqHeader X-Forwarded-Proto: https
-- BereqHeader X-Forwarded-Port: 443
-- BereqHeader Host: server.com
-- BereqHeader X-Amzn-Trace-Id: Root=1-5c9364f3-26a603e3ce2f87d9923ed27e
-- BereqHeader Content-Length: 53
-- BereqHeader Accept: application/json
-- BereqHeader Authorization: Bearer 3pa8ot18dlmpad2s34a5gt3p08jg0ml5
-- BereqHeader Content-Type: application/json; charset=utf-8
-- BereqHeader Cookie: PHPSESSID=o1f3010cuch8iu055stl6q1s03
-- BereqHeader X-Forwarded-For: 62.103.214.39, 172.31.19.159
-- BereqHeader X-Varnish: 42221069
-- VCL_call BACKEND_FETCH
-- VCL_return fetch
-- BackendOpen 32 reload_20190304_175528_18074.live1 172.31.11.111 8081 172.31.31.198 39914
-- BackendStart 172.31.11.111 8081
-- Timestamp Bereq: 1553163507.952205 0.819485 0.819485
-- FetchError HTC status -1
-- BackendClose 32 reload_20190304_175528_18074.live1
-- Timestamp Beresp: 1553163507.952235 0.819514 0.000029
-- Timestamp Error: 1553163507.952237 0.819517 0.000003
-- BerespProtocol HTTP/1.1
-- BerespStatus 503
-- BerespReason Service Unavailable
-- BerespReason Backend fetch failed
-- BerespHeader Date: Thu, 21 Mar 2019 10:18:27 GMT
-- BerespHeader Server: Varnish
-- VCL_call BACKEND_ERROR
-- BerespHeader Content-Type: text/html; charset=utf-8
-- BerespHeader Retry-After: 5
-- VCL_return deliver
-- Storage malloc Transient
-- ObjProtocol HTTP/1.1
-- ObjStatus 503
-- ObjReason Backend fetch failed
-- ObjHeader Date: Thu, 21 Mar 2019 10:18:27 GMT
-- ObjHeader Server: Varnish
-- ObjHeader Content-Type: text/html; charset=utf-8
-- ObjHeader Retry-After: 5
-- Length 285
-- BereqAcct 451 53 504 0 0 0
-- End
From what we understand, Varnish is reporting a connection closed (EOF) from Apache but again Apache is not reporting anything on it's side.
We need to somehow get to the bottom of this as it is effecting service agreement.
Any ideas on tracing and solving the problem?

You don't have an Apache access log because the request is not fully handled by Apache as there is a problem before.
This kind of problem could lead to this situation:
network issue
Apache error, like too many requests, invalid request or some internal error
System error, like too many open files for the Apache user
Where you can look for traces:
Apache error log
System error log
Run a tcpdump (tshark/wireshark are good tools for this) and look for errors

Related

503 Service unavailable Apache, Magento 2, Varnish, Redis

i have a digitalocean droplet 1 click Magento 2 install that has Redis & Varnish, and because varnish uses port 80 so installing SSL is a little bit tricky, that i had to include http --http-01-port 8080 so it works, today was supposed to be the certificate renewal but it didn't auto renew and i received site not secured error, so i logged in to the server and i renewed the certificate using
certbot --force-renewal --http-01-port 8080 -d domainname.com,www.domainname.com
and the renewal is done, but after i did that i'm now receiving 503 Service unavailable with varnish disabled and with varnish enabled i receive Error 503 backend fetch failed
/etc/varnish/default.vcl
backend default {
.host = "localhost";
.port = "8080";
.first_byte_timeout = 600s;
.probe = {
.url = "/health_check.php";
.timeout = 2s;
.interval = 5s;
.window = 10;
.threshold = 5;
}
/etc/apache2/sites-enabled/000-default.conf
<VirtualHost 127.0.0.1:8080>
ServerAdmin webmaster#localhost
ServerName domainname.com
ServerAlias www.domainname.com
DocumentRoot /var/www/html/pub
<Directory /var/www/html/pub>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SetEnvIf X-Forwarded-Proto https HTTPS=on
RewriteEngine on
RewriteCond %{SERVER_NAME} =domainname.com [OR]
RewriteCond %{SERVER_NAME} =www.domainname.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
my apache error log shows
[Sun Sep 25 12:08:54.528941 2022] [proxy_http:error] [pid 51038] [client IP:19124] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
the 503 error showing even in Phpmyadmin, so i guess this error has nothing to do with Magento
what could be the issue?
Edit:
sudo varnishlog -g request -q "RespStatus == 503"
* << Request >> 2
- Begin req 1 rxreq
- Timestamp Start: 1664111575.119591 0.000000 0.000000
- Timestamp Req: 1664111575.119591 0.000000 0.000000
- VCL_use boot
- ReqStart 127.0.0.1 7840 a0
- ReqMethod GET
- ReqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY3VzdG9tZXIvYWNjb3VudC9sb2dpblBvc3QvcmVmZXJlci9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WTIxekwyNXZjbTkxZEdVdmFXNWtaWGd2ZFdWdVl5OWhTRkl3WTBoTk5reDVPRE5sVjBab1lYazFhbUl5TU
- ReqProtocol HTTP/1.1
- ReqHeader Host: domain.com
- ReqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
- ReqHeader Accept-Encoding: gzip,deflate
- ReqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-For: 185.191.171.40
- ReqHeader X-Forwarded-Host: domain.com
- ReqHeader X-Forwarded-Server: domain.com
- ReqHeader Connection: Keep-Alive
- ReqUnset X-Forwarded-For: 185.191.171.40
- ReqHeader X-Forwarded-For: 185.191.171.40, 127.0.0.1
- VCL_call RECV
- ReqHeader grace: none
- ReqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY3VzdG9tZXIvYWNjb3VudC9sb2dpblBvc3QvcmVmZXJlci9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WTIxekwyNXZjbTkxZEdVdmFXNWtaWGd2ZFdWdVl5OWhTRkl3WTBoTk5reDVPRE5sVjBab1lYazFhbUl5TU
- ReqUnset Accept-Encoding: gzip,deflate
- ReqHeader Accept-Encoding: gzip
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 3 fetch
- Timestamp Fetch: 1664111575.120014 0.000422 0.000422
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Sun, 25 Sep 2022 13:12:55 GMT
- RespHeader Server: Varnish
- RespHeader content-type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 2
- 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: 2
- RespUnset Via: 1.1 varnish (Varnish/6.4)
- VCL_return deliver
- Timestamp Process: 1664111575.120075 0.000484 0.000061
- Filters
- RespHeader Content-Length: 278
- RespHeader Connection: keep-alive
- Timestamp Resp: 1664111575.120135 0.000544 0.000060
- ReqAcct 791 0 791 269 278 547
- End
** << BeReq >> 3
-- Begin bereq 2 fetch
-- VCL_use boot
-- Timestamp Start: 1664111575.119704 0.000000 0.000000
-- BereqMethod GET
-- BereqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY3VzdG9tZXIvYWNjb3VudC9sb2dpblBvc3QvcmVmZXJlci9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WTIxekwyNXZjbTkxZEdVdmFXNWtaWGd2ZFdWdVl5OWhTRkl3WTBoTk5reDVPRE5sVjBab1lYazFhbUl5TU
-- BereqProtocol HTTP/1.1
-- BereqHeader Host: domain.com
-- BereqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
-- BereqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
-- BereqHeader X-Forwarded-Proto: https
-- BereqHeader X-Forwarded-Host: domain.com
-- BereqHeader X-Forwarded-Server: domain.com
-- BereqHeader X-Forwarded-For: 185.191.171.40, 127.0.0.1
-- BereqHeader grace: none
-- BereqHeader Accept-Encoding: gzip
-- BereqHeader X-Varnish: 3
-- VCL_call BACKEND_FETCH
-- VCL_return fetch
-- FetchError backend default: unhealthy
-- Timestamp Beresp: 1664111575.119731 0.000027 0.000027
-- Timestamp Error: 1664111575.119732 0.000028 0.000000
-- BerespProtocol HTTP/1.1
-- BerespStatus 503
-- BerespReason Backend fetch failed
-- BerespHeader Date: Sun, 25 Sep 2022 13:12:55 GMT
-- BerespHeader Server: Varnish
-- VCL_call BACKEND_ERROR
-- BerespHeader content-type: text/html; charset=utf-8
-- BerespHeader Retry-After: 5
-- VCL_return deliver
-- Storage malloc Transient
-- Length 278
-- BereqAcct 0 0 0 0 0 0
-- End
* << Request >> 5
- Begin req 4 rxreq
- Timestamp Start: 1664111597.397651 0.000000 0.000000
- Timestamp Req: 1664111597.397651 0.000000 0.000000
- VCL_use boot
- ReqStart 127.0.0.1 47420 a0
- ReqMethod GET
- ReqURL /robots.txt
- ReqProtocol HTTP/1.1
- ReqHeader Host: domain.com
- ReqHeader Accept: text/plain,text/html,*/*
- ReqHeader User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
- ReqHeader Accept-Encoding: gzip, deflate, br
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-For: 66.249.66.47
- ReqHeader X-Forwarded-Host: domain.com
- ReqHeader X-Forwarded-Server: domain.com
- ReqHeader Connection: Keep-Alive
- ReqUnset X-Forwarded-For: 66.249.66.47
- ReqHeader X-Forwarded-For: 66.249.66.47, 127.0.0.1
- VCL_call RECV
- ReqHeader grace: none
- ReqURL /robots.txt
- ReqUnset Accept-Encoding: gzip, deflate, br
- ReqHeader Accept-Encoding: gzip
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 6 fetch
- Timestamp Fetch: 1664111597.397807 0.000156 0.000156
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Sun, 25 Sep 2022 13:13:17 GMT
- RespHeader Server: Varnish
- RespHeader content-type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 5
- 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: 5
- RespUnset Via: 1.1 varnish (Varnish/6.4)
- VCL_return deliver
- Timestamp Process: 1664111597.397819 0.000167 0.000011
- Filters
- RespHeader Content-Length: 278
- RespHeader Connection: keep-alive
- Timestamp Resp: 1664111597.397856 0.000205 0.000037
- ReqAcct 342 0 342 269 278 547
- End
** << BeReq >> 6
-- Begin bereq 5 fetch
-- VCL_use boot
-- Timestamp Start: 1664111597.397716 0.000000 0.000000
-- BereqMethod GET
-- BereqURL /robots.txt
-- BereqProtocol HTTP/1.1
-- BereqHeader Host: domain.com
-- BereqHeader Accept: text/plain,text/html,*/*
-- BereqHeader User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
-- BereqHeader X-Forwarded-Proto: https
-- BereqHeader X-Forwarded-Host: domain.com
-- BereqHeader X-Forwarded-Server: domain.com
-- BereqHeader X-Forwarded-For: 66.249.66.47, 127.0.0.1
-- BereqHeader grace: none
-- BereqHeader Accept-Encoding: gzip
-- BereqHeader X-Varnish: 6
-- VCL_call BACKEND_FETCH
-- VCL_return fetch
-- FetchError backend default: unhealthy
-- Timestamp Beresp: 1664111597.397732 0.000015 0.000015
-- Timestamp Error: 1664111597.397733 0.000016 0.000000
-- BerespProtocol HTTP/1.1
-- BerespStatus 503
-- BerespReason Backend fetch failed
-- BerespHeader Date: Sun, 25 Sep 2022 13:13:17 GMT
-- BerespHeader Server: Varnish
-- VCL_call BACKEND_ERROR
-- BerespHeader content-type: text/html; charset=utf-8
-- BerespHeader Retry-After: 5
-- VCL_return deliver
-- Storage malloc Transient
-- Length 278
-- BereqAcct 0 0 0 0 0 0
-- End
* << Request >> 32770
- Begin req 32769 rxreq
- Timestamp Start: 1664111601.616549 0.000000 0.000000
- Timestamp Req: 1664111601.616549 0.000000 0.000000
- VCL_use boot
- ReqStart 127.0.0.1 47432 a0
- ReqMethod GET
- ReqURL /fr/stores/store/redirect/___store/en/___from_store/fr/uenc/aHR0cHM6Ly83eWFhay5jb20vZW4vY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZZWEl2YUc5MWMyVm9iMnhrTG1oMGJXd19jRDB6L3Byb2R1Y3QvNDEzLw,,/
- ReqProtocol HTTP/1.1
- ReqHeader Host: domain.com
- ReqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
- ReqHeader Accept-Encoding: gzip,deflate
- ReqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-For: 185.191.171.22
- ReqHeader X-Forwarded-Host: domain.com
- ReqHeader X-Forwarded-Server: domain.com
- ReqHeader Connection: Keep-Alive
- ReqUnset X-Forwarded-For: 185.191.171.22
- ReqHeader X-Forwarded-For: 185.191.171.22, 127.0.0.1
- VCL_call RECV
- ReqHeader grace: none
- ReqURL /fr/stores/store/redirect/___store/en/___from_store/fr/uenc/aHR0cHM6Ly83eWFhay5jb20vZW4vY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZZWEl2YUc5MWMyVm9iMnhrTG1oMGJXd19jRDB6L3Byb2R1Y3QvNDEzLw,,/
- ReqUnset Accept-Encoding: gzip,deflate
- ReqHeader Accept-Encoding: gzip
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 32771 fetch
- Timestamp Fetch: 1664111601.616769 0.000220 0.000220
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Sun, 25 Sep 2022 13:13:21 GMT
- RespHeader Server: Varnish
- RespHeader content-type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 32770
- 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: 32770
- RespUnset Via: 1.1 varnish (Varnish/6.4)
- VCL_return deliver
- Timestamp Process: 1664111601.616782 0.000233 0.000013
- Filters
- RespHeader Content-Length: 282
- RespHeader Connection: keep-alive
- Timestamp Resp: 1664111601.616807 0.000258 0.000024
- ReqAcct 615 0 615 269 282 551
- End
** << BeReq >> 32771
-- Begin bereq 32770 fetch
-- VCL_use boot
-- Timestamp Start: 1664111601.616650 0.000000 0.000000
-- BereqMethod GET
-- BereqURL /fr/stores/store/redirect/___store/en/___from_store/fr/uenc/aHR0cHM6Ly83eWFhay5jb20vZW4vY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZZWEl2YUc5MWMyVm9iMnhrTG1oMGJXd19jRDB6L3Byb2R1Y3QvNDEzLw,,/
-- BereqProtocol HTTP/1.1
-- BereqHeader Host: domain.com
-- BereqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
-- BereqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
-- BereqHeader X-Forwarded-Proto: https
-- BereqHeader X-Forwarded-Host: domain.com
-- BereqHeader X-Forwarded-Server: domain.com
-- BereqHeader X-Forwarded-For: 185.191.171.22, 127.0.0.1
-- BereqHeader grace: none
-- BereqHeader Accept-Encoding: gzip
-- BereqHeader X-Varnish: 32771
-- VCL_call BACKEND_FETCH
-- VCL_return fetch
-- FetchError backend default: unhealthy
-- Timestamp Beresp: 1664111601.616665 0.000014 0.000014
-- Timestamp Error: 1664111601.616665 0.000015 0.000000
-- BerespProtocol HTTP/1.1
-- BerespStatus 503
-- BerespReason Backend fetch failed
-- BerespHeader Date: Sun, 25 Sep 2022 13:13:21 GMT
-- BerespHeader Server: Varnish
-- VCL_call BACKEND_ERROR
-- BerespHeader content-type: text/html; charset=utf-8
-- BerespHeader Retry-After: 5
-- VCL_return deliver
-- Storage malloc Transient
-- Length 282
-- BereqAcct 0 0 0 0 0 0
-- End
* << Request >> 8
- Begin req 7 rxreq
- Timestamp Start: 1664111607.366603 0.000000 0.000000
- Timestamp Req: 1664111607.366603 0.000000 0.000000
- VCL_use boot
- ReqStart 127.0.0.1 13422 a0
- ReqMethod GET
- ReqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WW5KaGJtUXZhRzU2TG1oMGJXdywvcHJvZHVjdC8xMTMwLw,,/
- ReqProtocol HTTP/1.1
- ReqHeader Host: domain.com
- ReqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
- ReqHeader Accept-Encoding: gzip,deflate
- ReqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-For: 185.191.171.5
- ReqHeader X-Forwarded-Host: domain.com
- ReqHeader X-Forwarded-Server: domain.com
- ReqHeader Connection: Keep-Alive
- ReqUnset X-Forwarded-For: 185.191.171.5
- ReqHeader X-Forwarded-For: 185.191.171.5, 127.0.0.1
- VCL_call RECV
- ReqHeader grace: none
- ReqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WW5KaGJtUXZhRzU2TG1oMGJXdywvcHJvZHVjdC8xMTMwLw,,/
- ReqUnset Accept-Encoding: gzip,deflate
- ReqHeader Accept-Encoding: gzip
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 9 fetch
- Timestamp Fetch: 1664111607.366837 0.000233 0.000233
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Sun, 25 Sep 2022 13:13:27 GMT
- RespHeader Server: Varnish
- RespHeader content-type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 8
- 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: 8
- RespUnset Via: 1.1 varnish (Varnish/6.4)
- VCL_return deliver
- Timestamp Process: 1664111607.366855 0.000252 0.000018
- Filters
- RespHeader Content-Length: 278
- RespHeader Connection: keep-alive
- Timestamp Resp: 1664111607.366893 0.000289 0.000037
- ReqAcct 610 0 610 269 278 547
- End
** << BeReq >> 9
-- Begin bereq 8 fetch
-- VCL_use boot
-- Timestamp Start: 1664111607.366701 0.000000 0.000000
-- BereqMethod GET
-- BereqURL /en/stores/store/redirect/___store/fr/___from_store/en/uenc/aHR0cHM6Ly83eWFhay5jb20vYXIvY2hlY2tvdXQvY2FydC9hZGQvdWVuYy9hSFIwY0hNNkx5ODNlV0ZoYXk1amIyMHZaVzR2WW5KaGJtUXZhRzU2TG1oMGJXdywvcHJvZHVjdC8xMTMwLw,,/
-- BereqProtocol HTTP/1.1
-- BereqHeader Host: domain.com
-- BereqHeader Accept: text/html, application/rss+xml, application/atom+xml, text/xml, text/rss+xml, application/xhtml+xml
-- BereqHeader User-Agent: Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
-- BereqHeader X-Forwarded-Proto: https
-- BereqHeader X-Forwarded-Host: domain.com
-- BereqHeader X-Forwarded-Server: domain.com
-- BereqHeader X-Forwarded-For: 185.191.171.5, 127.0.0.1
-- BereqHeader grace: none
-- BereqHeader Accept-Encoding: gzip
-- BereqHeader X-Varnish: 9
-- VCL_call BACKEND_FETCH
-- VCL_return fetch
-- FetchError backend default: unhealthy
-- Timestamp Beresp: 1664111607.366723 0.000021 0.000021
-- Timestamp Error: 1664111607.366724 0.000022 0.000001
-- BerespProtocol HTTP/1.1
-- BerespStatus 503
-- BerespReason Backend fetch failed
-- BerespHeader Date: Sun, 25 Sep 2022 13:13:27 GMT
-- BerespHeader Server: Varnish
-- VCL_call BACKEND_ERROR
-- BerespHeader content-type: text/html; charset=utf-8
-- BerespHeader Retry-After: 5
-- VCL_return deliver
-- Storage malloc Transient
-- Length 278
-- BereqAcct 0 0 0 0 0 0
-- End
Backend unhealthy
I noticed the following log line in your log output:
-- FetchError backend default: unhealthy
This means that your backend is administratively set to an unhealthy state because too many health checks failed.
See https://www.varnish-software.com/developers/tutorials/troubleshooting-varnish/#backend-health-monitoring for a handy tutorial about backend health monitoring in Varnish
You could run sudo varnishlog -g raw -i Backend_health to validate this and see how many failures have taken place.
Backend health criteria
The criteria for the backend to be considered healthy in your configuration are the following:
The backend should connect within 3.5 seconds (default value)
The first byte should be received within 600 seconds after sending the backend request
The response should have a 200 status code
5 (the threshold value) out of 10 (the window value) health checks should succeed
Debugging the health check probe
In your VCL code /health_check.php is the endpoint of the health check probe. Run the following command to debug what's going on when Varnish loads it every 5 seconds:
sudo varnishlog -g request -q "ReqUrl eq '/health_check.php'"
You can add the output of this command to your question and I'll help you debug.
However, if the returned status code for these health checks is 404, it means you're using the wrong URL and you need to fix that first.
See https://www.varnish-software.com/developers/tutorials/configuring-varnish-magento/#fixing-the-backend-health-checks-for-magento-24 for a tutorial section about a common mistake in Magento when using health_check.php.

how to use httpwebrequest to login to site in vb.net

i want to login to site with my account but using vb.net "httpwebrequest"
this is the header :
http://www.alexasurfing.com/login?task=user.login
POST /login?task=user.login HTTP/1.1
Host: www.alexasurfing.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.alexasurfing.com/login
Cookie: __cfduid=d09a17b9b5acf54646546541471462027; refid=14786;
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 159
username=GMAL%40gmail.com&password=PASWW&remember=yes
HTTP/1.1 303 See other
Date: Wed, 17 Aug 2016 19:30:48 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.17
Location: /dashboard/profile
Server: cloudflare-nginx
i dont know how to use httpwebrequest to login to the site with my account ?
See the example here:
HTTP request with post
your post data is: username=GMAL%40gmail.com&password=PASWW&remember=yes
Note: You are sending plain text password over http. If there's an https option you should use that.

Why does the web server sent the file instead of a 304 http: not modified?

My browser send to the server the following request:
Host: www.imprimante.be
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: */*
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 29 May 2015 14:22:44 GMT
If-None-Match: "90-5173935ad3a1a-gzip"
Referer: http://www.imprimante.be/premier-avis-gratuit/
Cookie: <hidden>
Connection: keep-alive
The url used is http://www.imprimante.be/wp-content/themes/mch_imprimante/js/theme.min.js? (note: www.imprimante.be is not accessible trough wlan yet)
And the server send me the file with this (status 200) http header:
Accept-Ranges: bytes
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 137
Content-Type: application/javascript
Date: Wed, 03 Jun 2015 07:18:03 GMT
Etag: "90-5173935ad3a1a-gzip"
Keep-Alive: timeout=5, max=99
Last-Modified: Fri, 29 May 2015 14:22:44 GMT
Server: Apache/2.4.10 (Debian)
Vary: Accept-Encoding
As you might notice (Last-Modified: Fri, 29 May 2015 14:22:44 GMT) the file hasn't been modified since the last request.
So I don't get why the response isn't a 304 status: not modified.
I'd really like to know why the caching of this files (and some others) doesn't work as I expect it.
It is bug in Apache. Turn off mod_deflate.

Connection issues from certain devices

Can't connect from device using custom authenticator and ChallengeHandler.
This is from Worklight 6.1.0.2 from an iPod Touch device. On the worklight server, we see this in the Stack Trace.
klight.console.controllers.UsersController from Application javax.ws.rs.core.Application
[10/8/14 15:20:04:170 CDT] 0000001c com.worklight.core.auth.impl.LoginContext E FWLSE0059E: Login into realm 'NullLoginModule' failed. Invalid gadget request format: /WorkExecution/iphone/my_custom_auth_request_urlnull. Unknown handler path: my_custom_auth_request_url. [project AnywhereWorkManagement]
com.worklight.gadgets.GadgetRuntimeException: Invalid gadget request format: /WorkExecution/iphone/my_custom_auth_request_urlnull. Unknown handler path: my_custom_auth_request_url
at com.worklight.gadgets.api.GadgetAP
Our challenge handler submits our Authentication information using this Javascript call:
challengeHandler.submitLoginForm(challengeHandler.getAuthURL(), loginOptions, l
Where getAuthURL returns the string "/my_custom_auth_request."
Strangely, other devices using the same application and worklight server are allowed to login successfully. Another weird datapoint is that if we popup the Worklight Settings panel on this iPod Touch device, and update the Worklight server information, the worklight login then seems to succeed.
Wireshark log from the failed connection:
POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/login HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (367413328)/Worklight/6.1.0.02.20141006-1624
Content-Length: 71
x-wl-platform-version: 6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Connection: keep-alive
x-wl-native-version: 1475155033
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Cookie: WL_PERSISTENT_COOKIE=ac72a920-b614-423d-8347-e4b5c96a4a1b
Origin: file://
Accept-Encoding: gzip, deflate
realm=CustomAuthenticationRealm&isAjaxRequest=true&x=0.7606244247872382HTTP/1.1 503 Service Unavailable
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Language: en-US
Content-Length: 0
Connection: Close
Date: Fri, 10 Oct 2014 14:32:15 GMT
Then after updating the Custom URL to remove the trailing slash, and relogging in, here's the wireshark log from the successful login:
POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/query HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (384405120)/Worklight/6.1.0.02.20141006-1624
Accept-Encoding: gzip, deflate
Content-Length: 210
x-wl-platform-version: 6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Connection: keep-alive
x-wl-native-version: 1475155033
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Cookie: WL_PERSISTENT_COOKIE=0983cfc8-8526-48c9-99cb-72659cb934b4; JSESSIONID=0000wSxsNgF79M62_UJTNmXKKYC:2e8ee48e-dec4-4c69-b8b4-ad37f839f1be
Origin: file://
WL-Instance-Id: okur33g93p35c9j7rvpk1r9g5j
adapter=OSLCGenericAdapter&procedure=getProperties&compressResponse&parameters=%5B%7B%22propertyNames%22%3A%5B%22si.auth.type%22%5D%7D%5D&__wl_deviceCtx=Ar1Cjm4_mo9jpBAA&isAjaxRequest=true&x=0.33572526928037405HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Type: application/json; charset=UTF-8
Cache-Control: no-cache, no-store, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Content-Length: 93
Date: Fri, 10 Oct 2014 14:43:15 GMT
/*-secure-
{"isSuccessful":true,"responseID":"1516","properties":{"si.auth.type":"maximo"}}*/POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/my_custom_auth_request_url HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (384405120)/Worklight/6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Accept: text/javascript, text/html, application/xml, text/xml, */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Connection: keep-alive
Cookie: WL_PERSISTENT_COOKIE=0983cfc8-8526-48c9-99cb-72659cb934b4; JSESSIONID=0000wSxsNgF79M62_UJTNmXKKYC:2e8ee48e-dec4-4c69-b8b4-ad37f839f1be
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Content-Length: 62
Origin: file://
Accept-Encoding: gzip, deflate
username=wilson&password=wilson&authType=maximo&langcode=en-USHTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Type: application/json; charset=UTF-8
Cache-Control: no-cache, must-revalidate
Content-Language: en-US
Transfer-Encoding: chunked
Date: Fri, 10 Oct 2014 14:43:15 GMT
19
{"authStatus":"complete"}
0
I found this in the server logs to correspond with that 503 error from worklight server (I can reproduce by POSTing the same login URL). However in our Worklight Console, there is only one version of each application listed for iphone.
[10/10/14 10:37:54:063 CDT] 00000485 com.worklight.gadgets.serving.GadgetAPIServlet E FWLSE0020E: Ajax request exception: The environment 'iphone' supports multiple versions, therefore you must request it with a version parameter. [project AnywhereWorkManagement]
[10/10/14 10:37:54:066 CDT] 00000485 com.worklight.gadgets.serving.GadgetAPIServlet E FWLSE0117E: Error code: 1, error description: INTERNAL_ERROR, error message: FWLSE0069E: An internal error occurred during gadget request [project AnywhereWorkManagement]The environment 'iphone' supports multiple versions, therefore you must request it with a version parameter., User Identity {wl_authenticityRealm=null, CustomAuthenticationRealm=null, wl_remoteDisableRealm=null, wl_antiXSRFRealm=null, wl_deviceAutoProvisioningRealm=null, wl_deviceNoProvisioningRealm=null, wl_anonymousUserRealm=null}. [project AnywhereWorkManagement]
Scott,
The workaround is to remove the trailing slash from the Server URL.
For a permanent fix I suggest that you will open a PMR so that the development team could investigate the issue closely.
When doing so, please provide a reproducible test case because the flow does work fine, but seems to not work in yours, so need to better understand where exactly it fails. Be sure to provide this question in the description.
It could be that you are altering the URL somewhere in your challenge handler?

WCF Streaming Service/Multiple GET requests from Media Player

I've run into a problem with a WCF streaming service. That problem is due to Windows Media Player submitting multiple GET statements when you tell it to load the URL. Simply put, the multiple GET statements cause the entire stream to be requested more than once.
I'm guessing each one of these requests has a specific task, such as possibly requesting metadata, media type, and so on. The problem is I cannot seem to find any specification as for these GET requests on the web, nor can I make much sense of the packet captured "GET" requests to determine what exactly they are expecting back.
The first GET statement (length 294):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: Windows-Media-Player/12.0.7601.17514\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Second (500~ packets later) GET statement (length 364):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Cache-Control: no-cache\r\n
Connection: Keep-Alive\r\n
Pragma: getIfoFileURI.dlna.org\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
GetContentFeatures.DLNA.ORG: 1\r\n
Host: serverName:port\r\n
Third (130~ packets later) GET statement (length 324):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
Icy-Metadata: 1\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Fourth (200~ packets later) GET statement (length 687):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514\r\n
Host: serverName\r\n
X-Accept-Authentication: Negotiate, NTLM, Digest, Basic\r\n
Pragma: version11-enabled=1\r\n
Pragma:
no-cache,rate=1.000,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0\r\n
Pragma: packet-pair-experiment=1\r\n
Pragma: pipeline-experiment=1\r\n
Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch,
com.microsoft.wm.predstrm, com.microsoft.wm.startupprofile\r\n
Pragma: xClientGUID={3300AD50-2C39-46c0-AE0A-1623CEEA9A7E}\r\n
Accept-Language: en-US, *;q=0.1\r\n
Fifth (40~ packets later) GET statement (length 294):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514 WMFSDK/12.0\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Sixth (200~ packets later) GET statement:
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514 WMFSDK/12.0\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Seventh/LAST (70~ packets later) GET statement:
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Cache-Control: no-cache\r\n
Connection: Keep-Alive\r\n
Pragma: getIfoFileURI.dlna.org\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
GetContentFeatures.DLNA.ORG: 1\r\n
Host: serverName:port\r\n
Has anyone run into this before or have any reference to what each of these GET requests is expecting in response? They can't possibly all want a new STREAM and WCF appears to not handle them without calling for a new stream.
Put this in htaccess
SetEnvIf User-Agent NSPlayer BAD_BOT
Order Allow,Deny
Allow from all
Deny from env=BAD_BOT
Please look at this post, for details:
http://www.webhostingtalk.com/showthread.php?t=637335