61
Các bài viết mới
62
日本オンラインTV / [NHK] WORLD-JAPAN
« Bài mới nhất gửi bởi admin vào lúc Thứ bảy, 16/03/2024, 07:03:14 pm »63
Postgresql / [PostgeSQL] latest news
« Bài mới nhất gửi bởi admin vào lúc Thứ năm, 14/03/2024, 09:14:13 am »64
PHP / [Composer] A Dependency Manager for PHP
« Bài mới nhất gửi bởi admin vào lúc Thứ tư, 13/03/2024, 10:27:08 pm »65
Affiliate / [Affiliate] A8.net
« Bài mới nhất gửi bởi admin vào lúc Thứ tư, 13/03/2024, 09:25:45 am »66
Pháp luật / [Cục XNC] Thủ tục xin Visa
« Bài mới nhất gửi bởi admin vào lúc Thứ tư, 13/03/2024, 08:49:55 am »67
NGINX / NGINX - Disable loggin inside an if block to block access
« Bài mới nhất gửi bởi admin vào lúc Thứ ba, 12/03/2024, 11:17:38 pm »In NGINX, when you use the return 403; directive inside an if block to block access, by default, this action is logged to the NGINX access log. If you want to block certain requests (e.g., from bots you've identified and flagged through the $blocked_bot variable) without logging these blocked requests to the access log, you'll need to employ a slightly different strategy, as NGINX does not provide a direct way to skip logging for specific conditions directly within its standard logging directives.
One common approach is to use a separate location block that handles requests meant to be blocked and not logged. Here's how you can do it:
Set up a named location that serves the 403 without logging: You use a named location (for example, @no_log_403) to return the 403 status. Within this location block, you can either disable logging or direct the logs to a different log file that you don't monitor.
Redirect blocked bots to the named location: Instead of directly returning 403 in the if block, you rewrite the request to the named location.
Here's an example configuration illustrating this approach:
In this configuration:
The map directive is used to flag user agents of bad bots as $blocked_bot.
If a request is identified as coming from a blocked bot, it is rewritten to the /blocked_bot URI.
The @blocked_bot named location matches this rewritten URI and serves a 403 response without logging the request (using access_log off;).
This setup ensures that requests from blocked bots are denied without polluting your main access log. Remember to adjust the criteria for identifying $blocked_bot as needed for your specific scenario.
One common approach is to use a separate location block that handles requests meant to be blocked and not logged. Here's how you can do it:
Set up a named location that serves the 403 without logging: You use a named location (for example, @no_log_403) to return the 403 status. Within this location block, you can either disable logging or direct the logs to a different log file that you don't monitor.
Redirect blocked bots to the named location: Instead of directly returning 403 in the if block, you rewrite the request to the named location.
Here's an example configuration illustrating this approach:
# Flag the bots or conditions you want to block without logging
map $http_user_agent $blocked_bot {
default 0;
~*badbot 1; # Example bot pattern
}
server {
listen 80;
# Main access log - requests blocked without logging won't appear here
access_log /var/log/nginx/access.log combined;
# Dummy log for blocked requests, you can ignore this file
# Alternatively, you can set it to /dev/null if you don't want to keep these logs at all
access_log /var/log/nginx/blocked.log combined if=$log_blocked;
# Regular location blocks and server configuration go here
if ($blocked_bot) {
set $log_blocked 0; # Do not log
rewrite ^ /blocked_bot last; # Redirect to a named location for handling
}
# Named location for handling blocked requests without logging
location @blocked_bot {
access_log off; # Disable logging for this location
return 403;
}
}
In this configuration:
The map directive is used to flag user agents of bad bots as $blocked_bot.
If a request is identified as coming from a blocked bot, it is rewritten to the /blocked_bot URI.
The @blocked_bot named location matches this rewritten URI and serves a 403 response without logging the request (using access_log off;).
This setup ensures that requests from blocked bots are denied without polluting your main access log. Remember to adjust the criteria for identifying $blocked_bot as needed for your specific scenario.
68
Google / Google developers
« Bài mới nhất gửi bởi admin vào lúc Thứ ba, 12/03/2024, 01:58:47 pm »69