bretlowery1

Think of the flow this way:

Welcome user or bad guy –> Internet –> Apache/Nginx Web Server –> WordPress

All of your plugins exist within WordPress, so everything you see traffic-wise in a WordPress plugin means that traffic got past Apache/Nginx all the way to WordPress. This means it hit everything hardware-wise up to and including your web server, since that’s where WordPress lives.

Once the traffic hit WordPress, your plugins that handle incoming requests are executed in a priority order, including Wordfence and your other security plugin. If either plugin decides it’s a request from a bad guy, that plugin returns a 403 or 503 or whatever non-200 HTTP code is appropriate. In Wordfence’s case, with it’s default settings, WordPress also serves a custom error page back to the bad guy. If all of your security plugins say “good guy”, WordPress serves an HTTP 200 (OK) status back with the actual web site page requested. In either the good or bad case, your web server is sending a page and an appropriate status code back to the requestor.

Enterprise sites usually have some sort of separate front end protection that sits between their actual web servers and incoming traffic and handles this separately so that bad traffic never hits the web server, but in your case and most smaller WordPress site cases, it’s all your web server and WordPress handling all of it. “Blocking” in this case is best thought of as “blocked from seeing legitimate content on my WordPress site” rather than “blocked from my WordPress site”. In your case, it sounds like Wordfence is being executed as a higher priority plugin before your other security plugin where you block the traffic, so Wordfence sees it and logs it first.

Make sense?

• This reply was modified 5 years, 12 months ago by bretlowery1.
• This reply was modified 5 years, 12 months ago by bretlowery1.