Closed mrEckendonk closed 5 years ago
Can you try testing with another referrer like zx6.ru to see if Cloudflare has some kind of prevention for what 100dollars-seo might be doing?
Unfortunately I do not use Cloudflare. But here you can see your problem is entirely Cloudflare related.
$ curl -I https://[domain1] -e http://100dollars-seo.com
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ curl -I https://[domain2] -e http://100dollars-seo.com
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ curl -I https://[domain3] -e http://100dollars-seo.com
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ curl -I https://[domain4] -e http://100dollars-seo.com
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ curl -I https://[domain1] -e http://100dollars-seo.com
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
Thanks for your info @mitchellkrogza disabling Cloudflare caching resolved it. Using it as DNS and some basic functions is fine. FYI tested with Nginx 1.17,1 so you can update you README.md
So keep with one question. curl -A with the first 2 test gives pure html, not code 200 OK. Does this mean it works. Thats a little unclear in the README.md
The other gives the correct as indicated
[19:55][root@server7.{private] html]# curl -I https://[domain1] -e http://100dollars-seo.com
curl: (56) TCP connection reset by peer
[19:58][root@server7.[private] html]# curl -I https://[domain1] -e http://zx6.ru
curl: (56) TCP connection reset by peer
[20:02][root@server7.[private] html]# curl -A "Xenu Link Sleuth/1.3.8" https://[domain1]
curl: (56) TCP connection reset by peer
[20:03][root@server7.[private} html]# curl -A "Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)" https://[domain1]
curl: (56) TCP connection reset by peer
I am busy with so many changes including updating documentation a few hundred commits this week :scream:
It should just be a curl -A "whatever" -I https://your domain.com
for quicker testing without the full code response
Thanks, my email box is full with you commits. Keep up the good work @mitchellkrogza
curl -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -I https://[domain1]
HTTP/1.1 200 OK
Sorry, did not see your request "Can you try testing with another referrer like zx6.ru", but that does not make any difference. Until now, we need to disable Cloudflare caching.
No ignore that it's purely just a Cloudflare thing, I just wasnt sure if they had some kind of other protection to detect naughty domains which is not the case
Got a message from the maintainer of the LEMP Stack that we use.
that is expected as Cloudflare is the one to receive your 443/444 blocked status message from Centmin Mod Nginx server which CF can't read so gives the 520 error which is what you'd want for blocked requests. So no need to disable Cloudflare cache for live use as you want bad bots to receive that 520 error from CF.
I guess that this is the same for other CDN's.
Thanks @Eckybrazzz this is very good info to have here for other users of CF. It shows CF will spare your server from being hit by a bunch of repetitive queries from the same BOT when on its first attempt you said 444 / Go Away :+1:
@mitchellkrogza, maybe an Idea to adjust your README step 10 in the meanwhile with "If using CF.... please disable the caching before testing... or something like that. I only disabled caching, and the issue was gone, I think that ALL CDN's act the same, but did not test that.
I recreated a new server because of this, thinking I did something wrong.
And a step with "suggestion" to keep the git up to date as you explain in an e-mail to me would be useful to.
#!/bin/bash
cd /path/to/nginx-ultimate-bad-bot-blocker/
git pull
# Send yourself an email - Not Necessary Though
exit ${?}
@Eckybrazzz readme now Auto updated on each build with all different versions used during tests
Describe the bug
curl -I Gives strange information when testing twice. First time it gives curl: (56) TCP connection reset by peer Second time it gives HTTP/1.1 520 Origin Error Test made on other server with 2 different domains
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Getting correct curl: (56) TCP connection reset by peer instead of 202
Copy of nginx.conf
If applicable please paste your nginx.conf file here (paste in between the
markers)
domain1
Copy of vhost / website / host .conf file
domain2
Copy of vhost / website / host .conf file
Operating System:
[ X] CentOS
Specify Exact Version of OS: 7.6 x64
Linux server8.[private] 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[16:45][root@server8.[private] conf.d]# nginx -V nginx version: nginx/1.17.1 (270619-130104-centos7-kvm) built by gcc 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC) built with OpenSSL 1.1.1c 28 May 2019 TLS SNI support enabled configure arguments: --with-ld-opt='-Wl,-E -L/usr/local/zlib-cf/lib -L/usr/local/lib -ljemalloc -lpcre -Wl,-z,relro -Wl,-rpath,/usr/local/zlib-cf/lib:/usr/local/lib' --with-cc-opt='-I/usr/local/zlib-cf/include -I/usr/local/include -m64 -march=native -DTCP_FASTOPEN=23 -g -O3 -Wno-error=strict-aliasing -fstack-protector-strong -flto --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wimplicit-fallthrough=0 -fcode-hoisting -Wp,-D_FORTIFY_SOURCE=2 -Wno-deprecated-declarations -gsplit-dwarf' --sbin-path=/usr/local/sbin/nginx --conf-path=/usr/local/nginx/conf/nginx.conf --build=270619-130104-centos7-kvm --with-compat --with-http_stub_status_module --with-http_secure_link_module --with-libatomic --with-http_gzip_static_module --add-dynamic-module=../ngx_brotli --add-dynamic-module=../ngx_http_geoip2_module --with-http_sub_module --with-http_addition_module --with-http_image_filter_module=dynamic --with-http_geoip_module --with-stream_geoip_module --with-stream_realip_module --with-stream_ssl_preread_module --with-threads --with-stream --with-stream_ssl_module --with-http_realip_module --add-dynamic-module=../ngx-fancyindex-0.4.2 --add-module=../ngx_cache_purge-2.5 --add-dynamic-module=../ngx_devel_kit-0.3.0 --add-dynamic-module=../set-misc-nginx-module-0.32 --add-dynamic-module=../echo-nginx-module-0.61 --add-module=../redis2-nginx-module-0.15 --add-module=../ngx_http_redis-0.3.7 --add-dynamic-module=../lua-nginx-module-0.10.15 --add-module=../stream-lua-nginx-module-0.0.7 --add-module=../memc-nginx-module-0.18 --add-module=../srcache-nginx-module-0.31 --add-dynamic-module=../headers-more-nginx-module-0.33 --with-pcre-jit --with-zlib=../zlib-cloudflare-1.3.0 --with-http_ssl_module --with-http_v2_module --with-openssl=../openssl-1.1.1c --with-openssl-opt='enable-ec_nistp_64_gcc_128 enable-tls1_3' --add-dynamic-module=../ModSecurity-nginx