리눅스, 아파치에서 검색 로봇 접근을 특정 요일에만 막고 싶은데, 설정 방법이 있나요?

아파치

 

리눅스, 아파치에서 검색 로봇 접근을 특정 요일에만 막고 싶은데, 설정 방법이 있나요?

Apache에서 특정 요일에만 로봇 접근을 차단하려면 mod_rewrite 모듈을 사용해 요일별로 요청을 제어할 수 있습니다. Apache의 RewriteCond 지시문을 활용하여 요일 조건을 설정할 수 있으며, 아래와 같이 설정 파일에 규칙을 추가해 주시면 됩니다.

1. Apache mod_rewrite 모듈 활성화

먼저, mod_rewrite 모듈이 활성화되어 있어야 합니다. 다음 명령어로 활성화하세요:

sudo a2enmod rewrite
sudo systemctl restart apache2

 

2. .htaccess 또는 Apache 설정 파일에 규칙 추가

.htaccess 파일이나 Apache 설정 파일 (/etc/apache2/sites-available/your-site.conf)에 다음 규칙을 추가합니다.

RewriteEngine On

# 요일 검사 (0은 일요일, 6은 토요일)
# 예: 일요일(0) 또는 토요일(6)에만 차단
RewriteCond %{TIME_WDAY} ^[06]$

# User-Agent에 "bot"이 포함된 경우 차단
RewriteCond %{HTTP_USER_AGENT} bot [NC]
RewriteRule ^ - [F]

 

설명

• RewriteCond %{TIME_WDAY} ^[06]$는 현재 요청의 요일을 확인하는 조건입니다. TIME_WDAY는 0에서 6 사이의 값을 가지며, 0이 일요일, 6이 토요일을 의미합니다. 위 예시는 일요일과 토요일에만 차단하도록 설정했습니다.
• RewriteCond %{HTTP_USER_AGENT} bot [NC]는 요청의 User-Agent가 "bot"을 포함할 때만 규칙이 적용되도록 합니다.
• RewriteRule ^ - [F]는 조건을 만족할 때 접근을 차단(403 Forbidden)하는 규칙입니다.

필요에 따라 요일이나 User-Agent 조건을 조정하여 원하는 요일과 특정 봇들에만 접근을 제한할 수 있습니다.

 

 

RewriteCond에 따른 RewriteRule이 여러 개일 경우에는 어떻게 설정해야 하나요?

RewriteCond와 RewriteRule을 함께 사용할 때, RewriteCond는 바로 다음에 오는 RewriteRule에만 적용됩니다. 여러 조건에 따른 다양한 RewriteRule을 설정하고 싶다면 각 RewriteRule마다 필요한 RewriteCond를 따로 지정해 주어야 합니다.

예시: 각 조건에 따른 개별 차단 규칙 설정

예를 들어, 요일별로 다른 User-Agent에 대해 차단 규칙을 설정하고 싶다고 가정해 보겠습니다.

RewriteEngine On

# 조건 1: 일요일에 "bot"을 포함하는 User-Agent 차단
RewriteCond %{TIME_WDAY} ^0$
RewriteCond %{HTTP_USER_AGENT} bot [NC]
RewriteRule ^ - [F]

# 조건 2: 월요일에 "crawler"를 포함하는 User-Agent 차단
RewriteCond %{TIME_WDAY} ^1$
RewriteCond %{HTTP_USER_AGENT} crawler [NC]
RewriteRule ^ - [F]

# 조건 3: 토요일에 "spider"를 포함하는 User-Agent 차단
RewriteCond %{TIME_WDAY} ^6$
RewriteCond %{HTTP_USER_AGENT} spider [NC]
RewriteRule ^ - [F]

 

설명

• RewriteCond %{TIME_WDAY} ^0$와 RewriteCond %{HTTP_USER_AGENT} bot [NC]는 일요일에 User-Agent가 "bot"을 포함하는 경우 차단하도록 설정합니다.
• 각 RewriteCond는 바로 다음에 있는 RewriteRule에만 적용되므로, 각 요일과 User-Agent에 대해 별도의 RewriteCond와 RewriteRule을 설정했습니다.
• 여러 RewriteCond가 하나의 RewriteRule에 연결될 경우, 모든 조건이 만족될 때만 해당 규칙이 적용됩니다 (AND 조건).

이렇게 설정하면 요일별로 각기 다른 로봇에 대한 접근을 제어할 수 있습니다.

 

 

BrowserMatchNoCase "SemrushBot-SA/" do_not_log is_a_robot 이렇게 설정한 것을 RewriteCond 에 적용할 수 있나요?

Apache의 BrowserMatchNoCase 지시문은 특정 User-Agent 문자열이 포함된 요청을 식별하고, 이를 바탕으로 환경 변수를 설정할 수 있습니다. 이 변수를 RewriteCond에 활용하여 조건부로 RewriteRule을 적용할 수 있습니다.

예를 들어, BrowserMatchNoCase "SemrushBot-SA/" do_not_log is_a_robot 설정을 추가한 뒤, 이 환경 변수를 RewriteCond에서 사용할 수 있습니다.

설정 예시

Apache 설정 파일(.htaccess 또는 사이트 설정 파일)에서 다음과 같이 구성할 수 있습니다:

# User-Agent에 "SemrushBot-SA/"가 포함되면 환경 변수 설정
BrowserMatchNoCase "SemrushBot-SA/" do_not_log is_a_robot

RewriteEngine On

# 조건 1: 환경 변수가 설정된 경우와 특정 요일에만 차단
# is_a_robot 변수가 설정된 경우
RewriteCond %{ENV:is_a_robot} ^1$
# 일요일(0) 또는 토요일(6)
RewriteCond %{TIME_WDAY} ^[06]$
RewriteRule ^ - [F]

# 조건 2: 환경 변수를 기반으로 로그 비활성화
SetEnvIf is_a_robot 1 no_log
CustomLog /var/log/apache2/access.log combined env=!no_log

 

설명

1. BrowserMatchNoCase "SemrushBot-SA/" do_not_log is_a_robot
   • User-Agent에 "SemrushBot-SA/" 문자열이 포함되면 do_not_log와 is_a_robot라는 환경 변수가 설정됩니다.
   • 이 설정은 대소문자를 구분하지 않으며, do_not_log는 Apache 로그를 제한하는 데 사용할 수 있고, is_a_robot는 조건문에서 사용됩니다.
2. RewriteCond %{ENV:is_a_robot} ^1$
   • RewriteCond는 is_a_robot 변수가 설정된 경우(즉, 값이 1인 경우)와 특정 요일(TIME_WDAY가 0 또는 6, 일요일 또는 토요일)에 접근을 차단합니다.
3. 로그 비활성화
   • SetEnvIf와 CustomLog를 사용해 is_a_robot가 설정된 요청은 no_log 환경 변수를 통해 Apache 액세스 로그에 기록되지 않도록 합니다.

이 구성을 통해 특정 요일과 조건에 따라 SemrushBot-SA/의 접근을 차단하고, 동시에 로그도 남기지 않도록 할 수 있습니다.

 

 

RewriteCond %{TIME_WDAY} ^[06]$ # 예: 일요일(0) 또는 토요일(6) 이 구문에서 RewriteCond: bad flag delimiters 라는 오류가 났습니다. 무엇이 잘못된 것일까요?

RewriteCond: bad flag delimiters 오류는 RewriteCond 지시문에서 정규 표현식이 잘못 작성되었거나 형식에 문제가 있을 때 발생할 수 있습니다.

RewriteCond %{TIME_WDAY} ^[06]$ 구문에는 문제는 없지만, 주석을 #로 추가할 때 잘못된 위치에 있을 가능성이 큽니다. Apache에서는 주석이 줄의 시작에 있어야 합니다. 즉, RewriteCond 구문과 같은 줄에 주석이 있을 경우 문제가 발생할 수 있습니다.

해결 방법

주석을 별도의 줄에 작성해 주세요. 다음과 같이 수정해 보세요:

# 예: 일요일(0) 또는 토요일(6)에만 차단
RewriteCond %{TIME_WDAY} ^[06]$
RewriteCond %{HTTP_USER_AGENT} bot [NC]
RewriteRule ^ - [F]

 

위와 같이 수정하면 bad flag delimiters 오류가 해결될 것입니다.

 

 

 

이런 설정으로 검색 로봇의 접근을 막으면 아파치에 접속할 수 있는 일반 사용자가 더 많아질까요?

검색 로봇의 접근을 막으면 Apache 서버에 접속할 수 있는 일반 사용자 수가 증가할 가능성이 있습니다. 특히 서버의 리소스가 한정된 환경에서는 검색 로봇이 주기적으로 접근하여 서버 부하를 높이는 경우가 많습니다. 검색 로봇의 요청을 제한하거나 차단하면 서버의 리소스 사용량이 줄어들어 일반 사용자에게 더 많은 리소스를 할당할 수 있게 됩니다.

다만, 로봇의 접근을 차단할 때 다음과 같은 점을 고려해야 합니다:

1. SEO 영향: Google, Bing 등 주요 검색 엔진의 크롤러(예: Googlebot)를 차단하면 검색 엔진 색인에 문제가 생길 수 있습니다. 이는 사이트가 검색 엔진에서 발견되기 어려워질 수 있다는 뜻이므로, 웹 트래픽이 줄어들 수 있습니다. 주의해야 할 로봇만 차단하고, 검색 엔진 크롤러는 허용하는 것이 좋습니다.
2. 서버 부하 감소: 일부 크롤러는 매우 빈번히 방문하여 서버에 부하를 줄 수 있습니다. 특히 트래픽이 많은 사이트라면, 불필요한 로봇의 접근을 차단함으로써 CPU와 메모리 자원을 확보해 일반 사용자의 페이지 로드 속도와 응답 시간을 개선할 수 있습니다.
3. 로봇 차단 우선순위 설정: 특정 시간대나 요일에 한정해 로봇을 차단하면 주간이나 비혼잡 시간에는 로봇이 접근할 수 있으므로, 검색 엔진 색인에도 큰 영향을 미치지 않으면서 서버 부하를 관리할 수 있습니다.

결론적으로, 설정한 대로 검색 로봇의 접근을 제어하면 서버 리소스가 절약되어 일반 사용자가 더 원활하게 접속할 수 있을 가능성이 높습니다.

 

 

 

RewriteCond %{HTTP_USER_AGENT} bot [NC] 이렇게 설정하면 모든 검색 로봇을 차단할 수 있는 것인가요? 혹시 검색 로봇이 아닌데 차단 되는 경우는 없나요?

RewriteCond %{HTTP_USER_AGENT} bot [NC] 설정은 User-Agent 문자열에 "bot"이 포함된 모든 요청을 차단하는 방식입니다. 이를 통해 많은 검색 로봇을 차단할 수 있지만, 예상치 못한 요청도 차단될 가능성이 있습니다. 다음은 이 설정의 장단점과 주의할 점입니다.

1. 장점

• 검색 로봇 차단: "bot"이라는 문자열을 User-Agent에 포함하는 대부분의 검색 로봇(예: "Googlebot," "Bingbot")을 차단할 수 있습니다.
• 간편한 설정: User-Agent에 포함된 특정 문자열을 기준으로 하기 때문에 설정이 간단하며 많은 로봇을 한 번에 차단할 수 있습니다.

2. 단점 및 주의 사항

• 비검색 로봇 차단 가능성: 일부 유효한 User-Agent에도 "bot"이라는 단어가 포함될 수 있습니다. 예를 들어, "robotics"와 같이 "bot"을 포함한 문자열을 사용하는 User-Agent가 있을 수 있습니다. 이 경우, 검색 로봇이 아닌 사용자가 차단될 수 있습니다.
• 제외 대상 오탐지 가능성: 특정 앱, 서비스, 또는 합법적인 자동화 도구가 "bot"을 User-Agent에 포함할 수 있어 이를 사용하는 일부 사용자 요청이 의도치 않게 차단될 수 있습니다.

검색 엔진 로봇을 선별적으로 차단하는 방법

검색 엔진의 주요 로봇만 차단하거나 허용하고 싶다면, 특정 User-Agent를 기반으로 차단 규칙을 더 세분화할 수 있습니다.

# Googlebot 차단
RewriteCond %{HTTP_USER_AGENT} Googlebot [NC]
RewriteRule ^ - [F]

# Bingbot 차단
RewriteCond %{HTTP_USER_AGENT} Bingbot [NC]
RewriteRule ^ - [F]

# SemrushBot 차단
RewriteCond %{HTTP_USER_AGENT} SemrushBot [NC]
RewriteRule ^ - [F]

 

추가로 고려할 수 있는 설정

차단 여부를 더 세밀하게 관리하기 위해, 일반 사용자를 차단하지 않으면서 불필요한 로봇들만 차단하려면 robots.txt 파일을 사용하여 검색 엔진에 대한 접근을 제어하는 방법도 있습니다. robots.txt 파일은 검색 엔진 로봇들이 사이트의 특정 부분에 접근하지 않도록 요청할 수 있는 방법으로, 서버 자원을 절약하면서도 검색 엔진 색인에 대한 제어를 세밀하게 할 수 있습니다.

User-agent: SemrushBot
Disallow: /

User-agent: AhrefsBot
Disallow: /

 

위와 같이 robots.txt에 설정해 두면 주요 검색 엔진들은 사이트의 요청을 존중하여 접근을 제한할 것입니다.

 

 

 

403 Forbidden을 사용하는 경우와 503 Service Temporarily Unavailable을 사용하는 경우가 어떤 차이가 있을까요? 503을 사용하려면 RewriteRule ^ - [F]에서 F대신에 무엇을 사용해야 할까요?

403 Forbidden과 503 Service Temporarily Unavailable 상태 코드는 서버에서 요청을 거부할 때 다른 목적을 가지고 사용됩니다.

• 403 Forbidden: 서버가 요청을 이해했지만, 권한이 없어서 요청을 거부한다는 의미입니다. 이 상태 코드는 영구적으로 접근이 금지된 경우에 주로 사용됩니다. 예를 들어, 특정 User-Agent나 IP를 차단할 때는 403 Forbidden이 적절합니다.
• 503 Service Temporarily Unavailable: 서버가 일시적인 문제로 요청을 처리할 수 없다는 의미로, 일시적인 접근 제한을 나타냅니다. 서버가 과부하 상태이거나 점검 중일 때 503을 사용하는 것이 좋습니다. 검색 엔진 크롤러에게도 이 상태 코드는 "잠시 후 다시 시도하라"는 신호를 주기 때문에, SEO에 미치는 영향이 적습니다.

503 상태 코드 설정 방법

RewriteRule에서 F 대신 R=503을 사용하여 503 Service Temporarily Unavailable 상태 코드를 반환할 수 있습니다.

RewriteEngine On

# 특정 요일과 User-Agent를 기반으로 503 에러 반환
# 일요일(0) 또는 토요일(6)
RewriteCond %{TIME_WDAY} ^[06]$
RewriteCond %{HTTP_USER_AGENT} bot [NC]
RewriteRule ^ - [R=503]

 

이 설정을 적용하면, 특정 요일에 User-Agent가 "bot"을 포함하는 요청이 들어올 때 503 상태 코드가 반환됩니다.

추가: Retry-After 헤더 설정

503 응답 시, 클라이언트에게 언제 다시 요청을 시도해야 하는지 알려주는 Retry-After 헤더를 추가하는 것이 좋습니다. 이 헤더는 Apache의 Header 지시문을 통해 설정할 수 있습니다.

# 503 응답 시 1시간 후에 재시도하라는 헤더 추가
Header always set Retry-After "3600"

 

이렇게 설정하면 검색 엔진과 클라이언트가 일정 시간이 지난 후에 다시 시도하도록 안내할 수 있습니다.

 

 

Retry-After 헤더 설정을 해 주지 않으면 어떻게 되나요?

Retry-After 헤더를 설정하지 않으면, 클라이언트(특히 검색 엔진 크롤러)는 서버가 언제 다시 이용 가능해질지에 대한 정보를 받지 못합니다. 이로 인해 다음과 같은 상황이 발생할 수 있습니다.

1. 과도한 재시도: 클라이언트와 크롤러는 서버가 언제 다시 사용 가능해질지 모르기 때문에, 서버에 반복적으로 요청을 시도할 수 있습니다. 특히 검색 엔진 크롤러는 주기적으로 다시 접근을 시도할 수 있는데, 이 경우 503 상태가 계속 반환되면 크롤링 빈도를 조절하는 데 어려움을 겪을 수 있습니다.
2. 검색 엔진의 색인 문제: 검색 엔진 크롤러는 Retry-After 헤더가 없을 때 서버의 상태를 판단하기 어렵습니다. 반복적인 503 응답이 검색 엔진에 기록되면, 일시적인 문제로 인식하지 않고 서버가 영구적으로 접근 불가능하다고 판단하여 페이지의 색인을 제거할 가능성도 있습니다. 이는 SEO에 부정적인 영향을 미칠 수 있습니다.
3. 사용자 경험 악화: 클라이언트 측에서는 서버가 복구되었는지 알기 어렵기 때문에, 다시 접근할 시점을 정확히 알 수 없습니다. 사용자나 클라이언트가 무작위로 서버에 재접속하려 할 수 있으며, 이는 불필요한 요청을 유발할 수 있습니다.

요약

Retry-After 헤더를 설정하면 클라이언트와 검색 엔진 크롤러가 서버 복구 시점을 예측하여 효율적으로 요청을 조정할 수 있습니다. 헤더 설정이 없는 경우, 재시도가 제어되지 않으면서 서버 부하가 증가하거나 검색 엔진 색인에서 사이트가 제외되는 등의 문제가 발생할 수 있습니다.

 

 

Retry-After 헤더 값은 503일 경우에만 적용되는 값인가요?

Retry-After 헤더는 주로 503 상태 코드와 함께 사용되지만, 반드시 503 응답에만 한정된 것은 아닙니다. 이 헤더는 클라이언트에게 언제 다시 요청을 시도할 수 있는지를 알리는 역할을 하며, 특정 상황에서는 503 외의 다른 상태 코드에서도 사용할 수 있습니다.

Retry-After 헤더가 사용되는 주요 HTTP 상태 코드

1. 503 Service Temporarily Unavailable
   • 503 응답과 함께 Retry-After를 설정하면, 클라이언트는 서버의 일시적인 문제로 인해 요청을 처리할 수 없음을 인지하고, 지정된 시간 후에 재시도할 수 있습니다. 이는 이 헤더의 가장 일반적인 사용 사례입니다.
2. 429 Too Many Requests
   • 서버가 짧은 시간 동안 너무 많은 요청을 받아 클라이언트의 요청을 거부할 때 반환하는 상태 코드입니다. Retry-After 헤더를 함께 설정하면, 클라이언트가 언제 다시 요청을 보낼 수 있는지 안내할 수 있습니다. 이는 API 서버 등에서 과도한 요청 제한 시 자주 사용됩니다.
3. 301 Moved Permanently 또는 302 Found
   • 리소스가 다른 URL로 이동되었을 때 반환하는 상태 코드입니다. 일반적으로 즉시 리다이렉트하지만, 경우에 따라 Retry-After 헤더를 추가해 일정 시간 후 리다이렉트할 것을 권장할 수 있습니다. 다만, 이는 드물게 사용되는 방법입니다.

Retry-After 헤더 값 형식

Retry-After 헤더에는 두 가지 형식으로 값을 설정할 수 있습니다.

• 초 단위로 시간 설정: 예를 들어, Retry-After: 3600은 1시간 후에 다시 시도하라는 뜻입니다.
• HTTP 날짜 형식: 예를 들어, Retry-After: Wed, 08 Nov 2024 14:00:00 GMT는 특정 날짜와 시간에 재시도하도록 안내하는 방법입니다.

요약

Retry-After 헤더는 주로 503 상태 코드와 함께 사용되지만, 429와 같은 다른 상태 코드에도 적용할 수 있습니다. 이를 통해 클라이언트에게 적절한 재시도 시점을 안내하여 불필요한 요청을 줄이고 서버 부하를 관리할 수 있습니다.

 

 

Retry-After 헤더 값으로 적정 값이 있을까요?

Retry-After 헤더의 적정 값은 상황에 따라 다르지만, 아래의 기준을 참고해 설정할 수 있습니다.

1. 일시적인 서버 과부하나 유지보수 중인 경우 (503 상태 코드)

• 짧은 중단: 5분(300초)
  • 일시적인 서버 부하, 짧은 유지보수 등에는 5분에서 1시간 정도의 Retry-After 값을 권장합니다. 검색 엔진 크롤러와 클라이언트가 짧은 시간 뒤에 재시도할 수 있도록 안내하는 데 적절합니다.
• 긴 유지보수: 1시간(3600초)
  • 시스템 점검 등으로 장시간 유지보수가 필요할 경우 1시간 이상의 값을 설정할 수 있습니다. 다만 너무 긴 재시도 시간을 설정하면, 사용자와 클라이언트의 경험에 악영향을 줄 수 있습니다. 가능한 한 예상 복구 시간을 정확하게 안내하는 것이 중요합니다.

2. 과도한 요청 제한 시 (429 상태 코드)

• 초 단위로 짧게 설정: 30초
  • API 서버 등에서 특정 클라이언트의 요청이 많아 429 상태 코드를 반환하는 경우에는 Retry-After를 짧게 설정합니다. 짧은 제한 시간 후에 재시도를 허용함으로써 사용자 경험에 미치는 영향을 줄일 수 있습니다.
• 재요청 간격을 증가: 10분 이상
  • 동일 클라이언트가 반복적으로 요청을 보내는 경우에는 Retry-After를 점차 증가시키는 방법도 효과적입니다. 초기에는 짧은 대기 시간(예: 30초)을 부여하고, 계속 요청이 과도하면 10분 이상으로 점차 늘리는 방식입니다.

3. 추천 값 요약

상황권장 Retry-After 값

짧은 유지보수	5분 (300초)
긴 유지보수	1시간(3600초)
과도한 요청 제한 (API)	30초, 점차 증가 가능

Retry-After 값은 사용자가 지나치게 오래 기다리지 않도록 적정 수준으로 설정하는 것이 중요합니다. 가능한 한 예상 복구 시간에 맞게 설정해 사용자와 검색 엔진이 적절히 대기할 수 있도록 유도하는 것이 좋습니다.

 

 

 

 

※ 참고사항 : 위의 내용으로 아파치 설정을 변경해서 정상 작동하는 것을 확인했습니다.

※ 주의사항 : ChatGPT와 나눈 대화를 정리한 것이므로 이 점을 고려해서 읽으시기를 권장합니다.

 

 

 

https://httpd.apache.org/docs/current/ko/sitemap.html

사이트맵 - Apache HTTP Server Version 2.4