«이전  1 ... 2 3 4 5 6 7 8 9 10 ... 11  다음»
출처 블로그 > Human Packet

/* ---------------------------------------------------------
  - 작 성  자 : 정찬호(
  - Homepage :
  - 최종수정일 : 2003. 12. 08
  - 모듈정보
    Apache DoS Evasive Maneuvers Module
    For Apache 1.3 and 2.0
    Copyright (c) 2002 Network Dweebs Corporation
    Version 1.8 [2003.0901.1845]
  ---------------------------------------------------------------- */

*. mod_dosevasive이란 무엇인가
  이것은 HTTP Dos 또는 DDos 스택 또는 저돌적인 공격으로부터 아파치를 보호하는데 있습니다.  이것은 ipchains, 방화벽, 라우터등으로 쉽게 구성될 수 있도록 디자인 되었습니다.

  탐지는 주소, URI의 IP 내부 동적 해쉬테이블을 생성함으로 수행되고, 각 아이피별로 거부됩니다.
  - 초당 몇번 이상의 같은 페이지를 요청하는 경우
  - 초당 같은 자식노드를 동시에 50번 이상 생성하는 경우
  - 일시적으로 블러킹되는 동안 어떠한 요청을 생성하는 경우


1. mod_dosevasive 설치
  다운로드 :

  [root@rootman root]# tar xvfz mod_dosevasive.1.8.tar.gz
  [root@rootman root]# cd /usr/local/apache/bin
  [root@rootman bin]# ./apxs  -iac ../mod_dosevasive/mod_dosevasive.c
  [root@rootman bin]# ./apxs  -iac ../mod_dosevasive/mod_dosevasive.c
     gcc -DLINUX=22 -DUSE_HSREGEX -fpic -DSHARED_CORE -DSHARED_MODULE -I/usr/local/apache/include  -c ../mod_dosevasive/mod_dosevasive.c
     gcc -shared -o ../mod_dosevasive/ mod_dosevasive.o
     [activating module `dosevasive' in /usr/local/apache/conf/httpd.conf]
     cp ../mod_dosevasive/ /usr/local/apache/libexec/
     chmod 755 /usr/local/apache/libexec/
     cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak
     cp /usr/local/apache/conf/ /usr/local/apache/conf/httpd.conf
     rm /usr/local/apache/conf/

  [root@rootman root]# vi /usr/local/apache/conf/httpd.conf     <--- 아래두줄이 추가되었나 확인한다.
       LoadModule dosevasive_module  libexec/
       AddModule mod_dosevasive.c

  [root@rootman /root]# /usr/local/apache/bin/apachectl graceful    <--- 아파치재가동시킨다.

2. httpd.conf에는 다음과 같이 설정을 추가한다.
    DOSHashTableSize     3097
    DOSPageCount         3
    DOSSiteCount         50
    DOSPageInterval      1
    DOSSiteInterval      1
    DOSBlockingPeriod    3600

  추가적으로 지시자를 추가하실 수 있습니다.
   DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"

 - DOSHashTableSize 
   각 자식 해쉬테이블 마다 탑레벨 노드의 수를 지정합니다.
   수치가 높으면 높을수록 더 많은 퍼포먼스가 나타나지만 테이블스페이스에 메모리를 남기게 된다.  접속량이 많으면 이 수치를 높혀도 된다.
 - DOSPageCount
   이것은 같은 페이지 또는 URI, 인터벌당 요청수에 대한 카운트 수이다.
   지정된 값이 초과되면 클라이언트에 대한 IP 정보가 블러킹리스트에 추가된다.

 - DOSSiteCount
   지정된 시간동안 같은 페이지를 지정된 수 보다 초과될경우 IP 정보가 블러킹리스트에 추가된다.

 - DOSPageInterval
   페이지 카운트 시발점, 디폴트는 1초이다.

 - DOSSiteInterval
   사이트 카운트 시발점, 디폴트는 역시 1초이다.

 - DOSBlockingPeriod
   클라이언트가 블랙리스트에 추가되어 블러킹되는 총 시간.
   이때 클라이언트는 403 (Forbidden) 에러를 출력하게 된다.

 - DOSEmailNotify
   이 값이 지정되면, IP가 블러킹될때마다 지정된 이메일로 발동된다.
   주의 : 메일러는 mod_dosevasive.c 에 정확하게 지정되야 한다.
         디폴트는 "/bin/mail -t %s" 이다.

 - DOSSystemCommand
   이 값이 지정되면, 시스템은 아이피가 블러킹될때마다 명령행을 실행한다.
   이것은 아이피 필터링이나 다른 도구를 사용하도록 설계되었습니다.


3. 인가된 IP 주소 할당
  버전 1.8에서는 아이피가 블러킹되더라도 인가된 클라이언트 아이피에 대해서는 적용되지 않습니다.   인가시키는 목적은 소프트웨어, 스크립트, 로컬서치로봇, 해당 서버로부터의 많은 요청인한 웹거부로 부터의 또다른 프로그램을 보호하는데 있습니다.

  아파치에서 설정하는 방법은 다음과 같습니다.

  DOSWhitelist    127.0.0.*

  와일드카드는(*) 필요하다면 최대 8진수(xxx.*.*.*)까지 사용할 수 있습니다.

4. 테스트 하기
  [root@rootman mod_dosevasive]# perl        
    HTTP/1.1 200 OK
    HTTP/1.1 403 Forbidden
    HTTP/1.1 200 OK
    HTTP/1.1 403 Forbidden
    HTTP/1.1 403 Forbidden

5. 원문보기
Apache DoS Evasive Maneuvers Module
For Apache 1.3 and 2.0
Copyright (c) 2002 Network Dweebs Corporation
Version 1.8 [2003.0901.1845]


This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.


mod_dosevasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack.  
It is also designed to be a detection tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera.  

Detection is performed by creating an internal dynamic hash table of IP Addresses and URIs, and denying any single IP address from any of the following:

- Requesting the same page more than a few times per second
- Making more than 50 concurrent requests on the same child per second
- Making any requests while temporarily blacklisted (on a blocking list)

This method has worked well in both single-server script attacks as well as distributed attacks, but just like other evasive tools, is only as useful to the point of bandwidth and processor consumption (e.g. the amount of bandwidth and processor required to receive/process/respond to invalid requests), which is why it's a good idea to integrate this with your firewalls and routers.

This module instantiates for each listener individually, and therefore has a built-in cleanup mechanism and scaling capabilities.  Because of this, legitimate requests are never compromised but only scripted attacks.  Even a user repeatedly clicking on 'reload' should not be affected unless they do it maliciously.

Two different module sources have been provided:

Apache v1.3 API:        mod_dosevasive.c
Apache v2.0 API:        mod_dosevasive20.c


A web hit request comes in.  The following steps take place:

- The IP address of the requestor is looked up on the temporary blacklist
- The IP address of the requestor and the URI are both hashed into a "key".  
 A lookup is performed in the listener's internal hash table to determine
 if the same host has requested this page more than once within the past 1 second.  
- The IP address of the requestor is hashed into a "key".
 A lookup is performed in the listerner's internal hash table to determine
 if the same host has requested more than 50 objects within the past second (from the same child).

If any of the above are true, a 403 response is sent.  
This conserves bandwidth and system resources in the event of a DoS attack.  
Additionally, a system command and/or an email notification can also be triggered to block all the originating addresses of a DDoS attack.

Once a single 403 incident occurs, mod_dosevasive now blocks the entire IP address for a period of 10 seconds (configurable).  
If the host requests a
page within this period, it is forced to wait even longer.  
Since this is triggered from requesting the same URL multiple times per second, this again does not affect legitimate users.

The blacklist can/should be configured to talk to your network's firewalls and/or routers to push the attack out to the front lines, but this is not required.

mod_dosevasive also performs syslog reporting using daemon.alert.  Messages
will look like this:

Aug  6 17:41:49 elijah mod_dosevasive[23184]: [ID 801097 daemon.alert] Blacklisting address x.x.x.x: possible DoS attack.


This tool is *excellent* at fending off small to medium-sized request-based DoS attacks or script attacks and brute force attacks.  
Its features will prevent you from wasting bandwidth or having a few thousand CGI scripts running as a result of an attack.  
When used in conjunction with other preventative measures such as router blackholing, this tool is very effective against larger DDoS attacks as well.

If you do not have an infrastructure capable of fending off any other types of DoS attacks, chances are this tool will only help you to the point of
your total bandwidth or server capacity for sending 403's.  
Without a solid infrastructure and DoS evasion plan in place, a heavy distributed DoS will most likely still take you offline.  



Without DSO Support:

1. Extract this archive into src/modules in the Apache source tree
2. Run ./configure --add-module=src/modules/dosevasive/mod_dosevasive.c
3. make, install
4. Restart Apache

With DSO Support, Ensim, or CPanel:

1. $APACHE_ROOT/bin/apxs -iac mod_dosevasive.c
2. Restart Apache


1. Extract this archive
2. Run $APACHE_ROOT/bin/apxs -i -a -c mod_dosevasive20.c
3. The module will be built and installed into $APACHE_ROOT/modules, and loaded into your httpd.conf
4. Restart Apache


mod_dosevasive has default options configured, but you may also add the following block to your httpd.conf:


   DOSHashTableSize    3097
   DOSPageCount        2
   DOSSiteCount        50
   DOSPageInterval     1
   DOSSiteInterval     1
   DOSBlockingPeriod   10


   DOSHashTableSize    3097
   DOSPageCount        2
   DOSSiteCount        50
   DOSPageInterval     1
   DOSSiteInterval     1
   DOSBlockingPeriod   10

Optionally you can also add the following directives:

   DOSSystemCommand        "su - someuser -c '/sbin/... %s ...'"

You will also need to add this line if you are building with dynamic support:

AddModule        mod_dosevasive.c

LoadModule dosevasive20_module modules/

(This line is already added to your configuration by apxs)

The hash table size defines the number of top-level nodes for each child's hash table.  
Increasing this number will provide faster performance by decreasing the number of iterations required to get to the record, but consume more memory for table space.  
You should increase this if you have a busy web server.  
The value you specify will automatically be tiered up to the next prime number in the primes list (see mod_dosevasive.c for a list of primes used).

This is the threshhold for the number of requests for the same page (or URI) per page interval.  
Once the threshhold for that interval has been exceeded, the IP address of the client will be added to the blocking list.

This is the threshhold for the total number of requests for any object by the same client on the same listener per site interval.  
Once the threshhold
for that interval has been exceeded, the IP address of the client will be added to the blocking list.

The interval for the page count threshhold; defaults to 1 second intervals.

The interval for the site count threshhold; defaults to 1 second intervals.

The blocking period is the amount of time (in seconds) that a client will be blocked for if they are added to the blocking list.  
During this time, all subsequent requests from the client will result in a 403 (Forbidden) and the timer being reset (e.g. another 10 seconds).  
Since the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a DoS attack, this timer will keep getting reset.


If this value is set, an email will be sent to the address specified
whenever an IP address becomes blacklisted.  A locking mechanism using /tmp
prevents continuous emails from being sent.

NOTE: Be sure MAILER is set correctly in mod_dosevasive.c
     (or mod_dosevasive20.c).  The default is "/bin/mail -t %s" where %s is
     used to denote the destination email address set in the configuration.  
     If you are running on linux or some other operating system with a
     different type of mailer, you'll need to change this.

If this value is set, the system command specified will be executed whenever an IP address becomes blacklisted.  
This is designed to enable system calls to ip filter or other tools.  
A locking mechanism using /tmp prevents continuous system calls.  
Use %s to denote the IP address of the blacklisted IP.


As of version 1.8, IP addresses of trusted clients can be whitelisted to insure they are never denied.  
The purpose of whitelisting is to protect software, scripts, local searchbots, or other automated tools from being denied for requesting large amounts of data from the server.  
Whitelisting should *not* be used to add customer lists or anything of the sort, as this will open the server to abuse.  
This module is very difficult to trigger without performing some type of malicious attack, and for that reason it is more appropriate to allow the module to decide on its own whether or not an individual customer should be blocked.

To whitelist an address (or range) add an entry to the Apache configuration
in the following fashion:

DOSWhitelist        127.0.0.*

Wildcards can be used on up to the last 3 octets if necessary.  
Multiple DOSWhitelist commands may be used in the configuration.


The keep-alive settings for your children should be reasonable enough to keep each child up long enough to resist a DOS attack (or at least part of one).  
For every child that exits, another 5-10 copies of the page may get through before putting the attacker back into '403 Land'.  
With this said,
you should have a very high MaxRequestsPerChild, but not unlimited as this will prevent cleanup.

You'll want to have a MaxRequestsPerChild set to a non-zero value, as DosEvasive cleans up its internal hashes only on exit.  
The default MaxRequestsPerChild is usually 10000.  
This should suffice in only allowing a few requests per 10000 per child through in the event of an attack (although if you use DOSSystemCommand to firewall the IP address, a hole will no longer be open in between child cycles).


Want to make sure it's working? Run, and view the response codes.
If the target machine is not localhost, be sure to change it in the script first.  
You should receive 403 responses after the first 25-50 requests, depending on your server configuration.  
Please don't use this script to DoS others without their permission.


- This module appears to conflict with the Microsoft Frontpage Extensions


Please email me with questions, constructive comments, or feedback:

From :

2006/09/11 10:25 2006/09/11 10:25
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > rulru님의 블로그
Apache 에서 DoS 공격 막기 (1.3.x 2.x 모두)
글쓴이 : 좋은진호 (2003년 08월 29일 오후 06:55) 읽은수: 6,699 [ 아파치 # 트랙백(0) 인쇄용 페이지 본문 E-Mail로 보내기 ]
아파치 작성자 : 좋은진호(truefeel, )
작성일 : 2003.8.20(수) apache v1.3.x
수정일 : 2003.8.25(월) apache v2.x 부분 추가

특정 URL이나 IP일 경우나 특정한 브라우저를 이용하여 DoS(Denial of Service, 서비스거부)
공격이 들어온다면 httpd.conf 에서 SetEnvIf, SetEnvIfNoCase 등과 Allow, Deny 설정으로
간단히 막을 수 있겠지만 일정한 유형이 없다면 해결점을 찾기가 쉽지 않다.

다행히 Apache용 mod_dosevasive 모듈로 DoS 공격을 쉽게 막을 수 있다.
며칠전 1.7버전 발표로 apache 2.x에서도 정상적으로 이 모듈을 이용할 수 있게 됐다.

1. mod_dosevasive 설치
에서 mod_dosevasive (현재 최신버전은 1.7)을 받아온다.

1) 기존에 사용하던 apache 1.3.x에 모듈만 추가할 때

mod_dosevasive.tar.gz 을 푼다음 apxs로 설치

# tar xvfz mod_dosevasive.tar.gz 
# cd dosevasive
# /bin/apxs -iac mod_dosevasive.c
[activating module `dosevasive' in /usr/local/apache/conf/httpd.conf]
cp /usr/local/apache/libexec/
chmod 755 /usr/local/apache/libexec/

httpd.conf의 LoadModule, AddModule는 apxs가 알아서 추가해준다.

2) apache 1.3.x부터 새로 컴파일할 할 때

mod_dosevasive.tar.gz 을 apache_source_홈/src/modules 에 푼 다음
기존에 apache 컴파일하는 것과 동일한 방법으로 하되, --add-module=... 옵션만

./configure --prefix=/usr/local/apache \
--enable-module=all --enable-shared=max \
--add-module=src/modules/dosevasive/mod_dosevasive.c  <-- 추가함
make install

3) apache 2.x에 모듈만 붙일 때

/bin/apxs -iac mod_dosevasive20.c

2. 설정

httpd.conf 에 아래 설정이 있는지 확인한다.

apache 1.3.x
LoadModule dosevasive_module libexec/
AddModule mod_dosevasive.c

apache 2.x
LoadModule dosevasive20_module modules/

httpd.conf에는 다음과 같이 설정을 추가한다.
( 단, 아래 설정 중에 apache 2.x일 때는 < IfModule mod_dosevasive20.c> 로 )
< IfModule mod_dosevasive.c>
  DOSHashTableSize  3097
  DOSPageCount    3
  DOSSiteCount    50
  DOSPageInterval   1
  DOSSiteInterval   1
  DOSBlockingPeriod  30
< /IfModule>
DOSHashTableSize  3097

hash table의 크기. IP, URI등을 분석하기 위한 공간으로 쓰이는 것 같은데 정확히는
모르겠다. 접속이 많은 서버이면 수치를 높인다.

DOSPageCount    3
DOSPageInterval   1

DOSPageInterval에서 지정한 시간(초단위)동안 같은 페이지를 3번 요청한 경우
해당 클라이언트 IP를 블럭킹한다. 블럭킹되는 동안에 사용자에게는 403(Forbidden)
코드가 전송된다.

DOSSiteCount    50
DOSSiteInterval   1

DOSSiteInterval에서 지정한 시간동안 어느 페이지나 이미지든 요청 건수가 50번을 넘는
경우 해당 클라이언트 IP를 블럭킹한다. 403코드 보내는 것은 마찬가지.
HTML 내에 이미지가 10개이면 요청 건수는 HTML포함하여 11번이 되므로 이미지가 많은
사이트는 숫자를 크게한다.

DOSBlockingPeriod  30

블럭킹된 IP는 30초동안 접속을 할 수 없다.

3. 모듈 사용을 중지하려면

차단 기능을 이용하지 않기 위해

DOSPageCount 0
DOSSiteCount 0

와 같이 하면 모듈 내부의 default값을 이용해서 동작하므로 LoadModule, AddModule를
주석 처리하는 방법을 써야한다. 또는 Count값을 상당히 큰 수를 지정할 수도 있겠다.

4. 차단하는지 테스트

간단한 테스트 툴로 test.pl을 제공한다.
12번째 줄에

printf("%03d ", $_ );

를 추가하고

apache를 실행시킨 다음 perl test.pl을 해보면 200 OK, 403 Forbidden 된 것을 쉽게
확인할 수 있을 것이다.

DOSPageCount, DOSSiteCount 수치를 너무 낮게 하면 정상적인 접속에 대해서도 차단될 수
있으므로 주의해야 한다. 수치를 낮추고, 같은 페이지를 reload(Ctrl+R)를 여러번했더니
바로 403 페이지가 등장.

403 페이지를 별도로 만드는 것이 좋을 듯 싶다. httpd.conf에 ErrorDocument 403 ... 설정
으로 html을 만들어두면 방문자에게 도움이 되지 않을까...

이젠 ab, lynx 등으로 게시물 조회수를 순간적으로 올린다거나, 시스템 로드를 증가시키는
것까지도 어느정도 막을 수 있을 것이다.

※ syslog 로 로그 남기는 기능과 DOSEmailNotify, DOSSystemCommand 옵션은 제대로 적용
  되지 않아 이 글에 적지 않았다. 정상동작이 확인되면 그 때 추가할 것이다.
2006/09/11 10:23 2006/09/11 10:23
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > [베베] 내 작은 버둥거림..

# cd /usr/local/src

# wget

# tar xvfz mod_evasive_1.10.1.tar.gz

# cd mod_evasive

# /usr/local/httpd/bin/apxs -i -a -c mod_evasive20.c


<IfModule mod_evasive20.c>
   DOSHashTableSize    3097
   DOSPageCount        5
   DOSSiteCount        50
   DOSPageInterval     1
   DOSSiteInterval     1
   DOSBlockingPeriod   30
   DOSEmailNotify      내 메일주소
   DOSLogDir           "/usr/local/apache/log/mod_evasive"

2006/09/11 10:23 2006/09/11 10:23
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 공부중...

아이피 주소를 도메인에 포워딩 하는중 문제가 발생했다. 잘 묵히던

팝업이 갑자기 안묵히고 난리다. 쿠키값을 확인해본 결과 잘 들어가져 있었으나 포워딩된

주소에서는 그 쿠키 값을 거부하고 있었다 ..

닷네임에서 확인해본 결과 아래와 같이 설명하고 있었다...


서로 다른 도메인을 포함하는 프레임 구조로 사이트를 IE6에서 열게 되면, 쿠키가 적용되지 않습니다.
이유는 마이크로 소프트에서 쿠키 정보의 남용을 막기 위해 p3p (Platform for Personal Preferences) 규약을 도입했기 때문입니다.
p3p (Platform for Personal Preferences) 규약은 W3C ( World wide Consortium )에서 만들어 졌습니다.
(마이크로 소프트 p3p 정책
(W3C - p3p 규약 )

그래서 다른 주소지로 연결되는 프레임구조로(특히 포워딩 고정 연결시) 웹페이지가 열리게 되면, 쿠키가 적용되지 않게 됩니다.

두가지 해결 방안이 있습니다.

첫번째는 쿠키를 적용하는 웹페이지에서 p3p 규약을 허용하는 HTTP 헤더를 추가하는 방법과
두번째는 쿠키를 적용하는 웹서버에서 p3p 규약을 허용하는 HTTP 헤더 추가하는 방법입니다.

무식하게 나마 세번째 방법이 있다.

세번째는 인터넷익스플로러에서 직접 설정을 해주는 것이다.

첫번째는 클라이언트 컴퓨터에서 볼때 설정해주는 것이다 즉 웹페이지에 직접 적어 넣는다.


< meta http - equiv = "p3p" content = 'CP="CAO DSP AND SO " policyref="/w3c/p3p.xml"' >


심플하게 php에 들어있는 자바스크립트로 만든 팝업등에서 써먹을 수도 있다.

두번째는  서버에서 직접 설정하는 것인데 왠지 께림찍해서 거부했다.

리누기 conf/httpd.conf 에 다음과 같이 추가한다.

<IfModule mod_headers.c>

그리고 데몬을 다시 구동 시켜야 겠지요?

세번째 무식한 방법

도구-인터넷옵션-개인정보-고급-자동쿠키덮어쓰기 (제3사 쿠키라고 한다.) 체크해주면 됨

기타 언어별 p3p 셋팅법

<meta http-equiv> 처럼 메타태그를 이용한 헤더 전송방법
아파치서버의 mod_headers 모듈을 이용한 방법
PHP 의 header 를 이용한 방법등이 있다.

jsp의 header

asp의 header

<meta http-equiv="p3p" content='CP="CAO DSP AND SO " policyref="/w3c/p3p.xml"' >

아파치서버 conf/httpd.conf :

<IfModule mod_headers.c>
#Header add P3P "CP=\"DSP CUR OTPi IND OTRi L FIN\""

php :

("p3p: CP=\"CAO DSP AND SO ON\" policyref=\"/w3c/p3p.xml\"");

혹은( 이상하게 아래것은 안묵히는것 같다.)





<% '//W3C P3P 규약설정 - ASP 버전


Response.setHeader("P3P","CP='CAO PSA CONi OTR OUR DEM ONL'");

p.s php에서 적용이 안돼서 팝업창과 부모창 모두에게

<title>  </title>
<meta http-equiv="p3p" content='CP="CAO DSP AND SO " policyref="/w3c/p3p.xml"' >

위와 같이 적용한 결과 해결되었음

written by soya98

2006/09/11 10:22 2006/09/11 10:22
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > Unix SE Blog
DSO 모드로 설치한다, 문제 생기면 제거 하기 쉬우니까~
   /usr/local/apache/bin/apxs -i -a -c mod_throttle.c
  ## 옵션 설명.
     -i : 라이브러리 디렉토리에 so 파일 복사하라는 옵션
     -a : httpd.conf 파일에 LoadModule 설정을 하라는 옵션
     -c : 컴파일 하라는 옵션

** 설정
   - httpd.conf 파일을 열어서 다음과 같이 설정한다.

       ## 사용자별 트래픽 모니터링 하기 위한 모듈을 로드한다. (접속자 많을때는 하지말것)
       LoadModule throttle_module    libexec/
               #예) 전체 설정을 1일 300G 로 한다면, 아래와같다.
               #ThrottlePolicy Volume 300G 1d // 1일 300 M 로 제한

         # 전체적인 상황을 보는 페이지
               Order deny,allow
               Deny from all
               ## 특정 ip만 열어준다.
               Allow from 피씨아이피
               SetHandler throttle-status

         ## 사용자 자신의 접속량 점검
               SetHandler throttle-me

               SetHandler throttle-me

        ## 통계결과를 3초에 한번씩 갱신하여 보여준다.((기본은 60)
        ThrottleRefresh 10
        ## 접속하는 ip들을 1000개 까지 보여주면 통계를 구하기 위해 제한을 두지 않았다.
        ThrottleClientIP 1000 none
        ## 아이피/~doly 으로 접속을 10초에 10번으로 제한하였다.
        ThrottleUser doly Request 10 10

## 정책들
None : 아무 정책이 없고, 단지 모니터링 용도로 사용할때 사용
Concurrent : 동시접속수를 제한하기위한 것인데.. 별루당
             (ThrottleClientIP, ThrottleRemoteUser와 같이 쓸수 없다.)
Document 요청제한수 기간 : Request와 비슷 단, html 형식의 문서만 카운트 한다.(그림파일 제외)
Idle 쉬는시간 기간 : 요청간에 쉬는 시간을 준다?? 왜??? <-- 이건 더 이해 해야 함.
Random 받아들이퍼센트 기간: 0이면 모두 거절, 100 이면 모두 허가, 중간갑이면 랜덤하게 허가^^;
Request 요청제한수 기간: 기간동안 받아들일 요청수 ^^;
Speed 제한용량 기간 : Volume 하고 비슷하지만, 요청을 거절하지 않고 연기(delay)시킨다.
Volume 제한용량 기간 : 기간동안 제한용량만큼을 준다.

## 항목들
SetHandler throttle-status : throttle의 상태를 보여준다.(관리자 모드)
   Context : server,,,

SetHandler throttle-me : throttle의 자기 상태를 보여준다.(사용자 모드)
   Context : server,,,

** ClinetIP별로 제한을 하기 위함((괜찮은 설정))
ThrottleClientIP 보여줄ip수 정책 제한 기간
   Context : server
   보여줄ip는 : 접속한 ip리스트 들이다.
   정책 : 위 정책들중의 하나를 선택하면 된다.^^ 제한,기간 위 정책에 따른다.

** 통계를 출력할 형태.(별의미 없다.)
ThrottleContentType 문자열
   Context : server
   문자열 : text/html, text/plain  이 둘중에 하나 넣으면 된다.

** 결과에 색을 달리할 퍼센테이지를 정한다. (별 의미 없다.)
   Context : server
ThrottleIndicator green 50
ThrottleIndicator yellow 75
ThrottleIndicator red 90

** throttle 에서 사용하는 파일들 (( 별 의미 없다.))
   Context : server
ThrottleLockFile /usr/local/apache/logs/throttle.lock
ThrottleRuntimeFile /usr/local/apache/logs/throttle.runtime

** Throttle 의 최대 Delay 시간 (기본 :60초,  0:제한하지 않음)
   Context : server
ThrottleMaxDelay 60

** Throttle 정책 설정  (가장 많이 사용 )
   Context : server,,,
ThrottlePolicy 정책 제한 기간
  가장 많이 사용한다. 정책은 Volume 관 Request 를 많이 사용해서 제한 한다.

** Throttle 통계화면 리로드 시간(기본 60초)
   Context : server
ThrottleRefresh 초단위시간
** Throttle RemoteUser ?? <== 이놈은 뭐에 쓰는 놈인지??
   Context : server
ThrottleRemoteUser 크기 정책 제한 기간

** 로컬사용자 제한 등록하기 (( 실 계정 사용자만 등록된다.)
   Context : server
ThrottleUser 사용자 정책 제한 기간
2006/09/11 10:22 2006/09/11 10:22
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 웃어...그래야 일류다

httpd.conf 파일은 크게 세부분으로 나누어져 있다.

Section 1: Global Environment : 아파치 전체적인 영향이 미치는 설정
Section 2: 'Main' server configuration : 주 서버에 대한 설정
Section 3: Virtual Hosts : 가상 호스트에 대한 설정

자, 그럼 이제부터 이 아파치웹서버의 모든 환경을 설정하는 아파치환경파일 httpd.conf파일의 설정방법에 대해서 상세히 알아보도록 하자.

### Section 1: Global Environment

전제환경설정 파트로 Section 1에서 설정하는 것들은 아파치 웹서버에
전반적인 영향을 미친다.

ServerType standalone

서버의 구동방법으로는 standalone과 inetd방식이 있는데, standalone
방식은 하나의 웹데몬(아파치서버)이 클라이언트의 접속을 모두 처리하는
방식으로 응답속도가 빠른 방법으로 주로 이방식을 사용한다. inetd 방식은
inetd라는 시스템의 /etc디렉토리 끝에 존재하는 inetd라는 슈퍼데몬이
클라이언트의 접속요구가 있을 때마다 웹서버를 구동하는 방식이다.
일반적으로 응답속도가 빠르고 효율적인 standalone으로 설정하여 사용한다.

ServerRoot "/usr/local/apache"

아파치서버의 홈디렉토리를 지정하며 절대경로로 지정한다. 이후로 나오는
대부분의 패스들은 이 경로에 대한 상대경로로 지정이 된다. 예를 들어
환경설정파일, 에러로그파일등의 상대경로의 기준이 되는 위치이다.

LockFile logs/accept.lock

LockFile의 경로지정시에 사용된다. 가급적 기본값으로 사용한다.

PidFile logs/

PidFile 설정은 ServerType을 Standalone으로 설정했을때만 유효한
것으로 아파치 서버의 프로세스가 생성되어 있을 때 그 프로세서ID(PID)를
기록하는 파일을 지정한다. 당연히 아파치서버가 재시작되거나 과부하로
인해 PID가 바뀌게 될 경우에는 이 파일의 PID값도 바뀌게 된다. 즉
다시말해서 여기서 지정된 파일(에 실행되고 있는 아파치서버의
프로세스번호(PID)값이 기록된다고 하면 정답이다. ServerRoot를 기준으로한
상대경로로 지정된다. 절대경로로 지정하려면 "/"로 시작하는 절대경로를
적어주면 된다.

ResourceConfig conf/srm.conf
AccessConfig conf/access.conf

아파치 서버의 환경설정파일은 3개이au httpd.conf, srm.conf, access.conf
가 그것이다. 그러나 하나의 설정파일로 하는 것이 효율적이기 때문에
지금은 httpd.conf파일안에 3개의 파트(Section)로 나누어서 하나의
파일안에서 설정을 하고 있다. srm.conf와 access.conf파일의 내용은 현재
비어있는 상태이지만, 필요하다면 이 파일 내에도 설정을 할 수 있다.
아파치 서버가 실행이 될 때는 httpd.conf, srm.conf, access.conf 순으로
언제나 이 3개의 파일을 모두 읽고 난뒤에 실행이 되기 때문이다. 만약 이
두 개의 파일을 서버가 무시하도록 하려면 다음과 같이 하거나 "#"으로 붙여
두면 주석처리되어 무시된다.

ResourceConfig /dev/null
AccessConfig /dev/null

Timeout 300

클라이언트의 요청에 의해 서버와 연결이 되었을 때 클라이언트와
서버간에 아무런 메시지가 발생하지 않았을 때 오류로 처리될 시간을
초단위로 설정한다. 초기값은 1200이며 보통은 300초로 지정을 한다.
네트웍의 속도가 나쁠수록 수치값은 높게 설정하는 것이 좋다.

KeepAlive On

접속한 채로 특별한 요청없이 지속적인 연결을 허용할 것인지를 설정한다.
허용하지 않으려면 off

MaxKeepAliveRequests 100

클라이언트가 접속된 시간동안 아파치서버에 요청할 수 있는 최대의
개수를 지정한다. 0을 지정하면 제한없음을 의미하며, 서버의 성능향상을
위하여 가능한 높은 값이 좋다.

KeepAliveTimeout 15

아파치 서버는 같은 접속상태의 클라이언트에서 여기서 지정한 초만큼의
요청이 없었을 때 접속을 끊게 된다.

MinSpareServers 5
MaxSpareServers 10

아파치 웹서버는 성능향상과 빠른 응답속도를 위해 유휴서버(현재
서비스대기 중인 프로세스)를 만들게 되는데 이 유휴서버의 개수는 시스템의
상황에 따라 달라지게 된다. 유휴서버가 MinSpareServers의 개수(5) 보다
적게되면 추가로 생성을 하게 되며 MaxSpareServers의 개수(10)보다 많게
되면 죽이게 된다. 즉, 유휴서버의 개수를 적절히 조절하기 위한 것이라
생각하면 된다.

StartServers 5

아파치 웹데몬이 구동될 때 자식프로세스를 몇 개로 할 것인가를
지정한다. 시작할 때 동시에 띄우게 될 웹데몬의 개수이다. 그러나 웹데몬이
구동되고 난 뒤엔 시스템의 상황(부하율등)에 따라 대부분 합리적인
개수만큼 동적으로 생성되었다가 죽기도 하므로 큰 의미를 가지는 것은

MaxClients 150

아파치웹서버에 접근할 수 있는 클라이언트의 최대갯수는 이 상한값으로
제한한다. 여기서 지정한 개수이상의 클라이언트의 요청이 생긴다면
아파치는 응답하지 않고 이 요청을 무시한다. 이를 제한하는 이유는
시스템의 자원을 아파치 웹서버가 무한정 차지하는 것을 방지하기 위한

MaxRequestsPerChild 30

아파치 웹서버의 자식프로세스들이 클라이언트의 요청 개수를 지정한다.
만약 자식프로세스가 이 값만큼의 클라이언트요청을 받았다면 이
자식프로세스는 자동으로 죽게된다. 이 값이 0으로 설정이 된다면
자식프로세스가 자동으로 죽는일은 없을 것이다. 그러나 0아닌 다른 값으로
설정함으로서 프로세스의 수를 적절히 조절하여 시스템의 부하조절과
자원낭비를 어느정도 방지 할 수 있다.

Listen 3000

시스템의 기본값이외에 다른 IP Address와 포트에 대해서도 연결할 수
있도록 해 준다. 환경설정파일(httpd.conf) 맨뒤에 나오는 가상호스트(Virtual
Host)부분에서 설정되는 가상호스트를 설정하기 위해 필요하다.

BindAddress *

서버가 응답할 수 있는 IP Address를 설정하는 것이다. 하나의 시스템에
있는 아파치웹서버 하나로 여러 웹서버처럼 관리하는 웹호스팅서비스등에서
많이 이용하는 것으로 여러 IP Address를 인식할 수 있게 한다. "*"으로
설정이 되었다면 모든 IP Address에 대해 응답할 수 있으며, IP Address를
지정한다면 지정한 IP Address에 대해서만 응답할 수 있게 된다. 여러개의
IP Address를 ISP로부터 할당받아서 웹호스팅서비스를 하고자 한다면
이부분에서 지정해 주면된다. 이 설정파일의 맨 뒷부분에 나오는
<VirtualHost>~</VirtualHost>부분의 IP bind 가상호스트부분에서 아파치
웹서버가 응답할 수 있도록 하려면 여기서 IP Address를 지정해 줘야 한다.

ExtendedStatus On

server-status로 아파치웹서버의 상태를 상태를 모니터링 할 때
"자세한상태정보"기능을 제공할 것인지(On) 아닌지(Off)를 설정하는 것이다.

### Section 2: 'Main' server configuration

Section 2에서 설정하는 항목들은 아파치의 주된서버가 사용할 값들을
지정한다. <VirtualHost>에 정의된 가상호스트들에서 지정하지 않는 것은
여기서 지정된 값이 기본값으로 적용된다. 또한 여기서 지정하는 값을 각
<VirtualHost>내에도 지정할 수 있으며 이경우엔 각<VirtualHost>내에서
지정한 값이 우선적용된다.

Port 80

아파치웹서버의 기본포트를 지정한다. 특별하게 사용하는 것이 아니라면
80번으로 해둬야 한다. 사용가능한 포트는 0 ~ 65535이며 1024이하의
포트번호는 시스템에서 특별하게 예약되어 있으므로 80번 이외의 다른
포트를 사용하려면 1024이상의 포트번호를 지정해서 사용해야 할 것이다.
특별한 지정이 없다면 <VirtualHost>에 정의된 각각의 가상호스트들의
기본포트가 된다. 만약 <VirtualHost> 내에서 Port가 지정이 된다면 그
포트번호가 우선한다.

(특별히 PORT를 따로 지정해 줄 필요가 있을 때는 따로 지정해 주며,
이때는 웹서버로 접근할 때 반드시 따로지정한 PORT번호로 접근해야 한다.
예를들어 Port 1234로 지정했다면, 접근시 :
로 접속해야한다. 단, 80번은 default이므로 Port번호를 입력하지 않아도
도메인만으로 그냥 접근할 수 있다. 예: )

User nobody
Group nobody

아파치 웹데몬이 요청을 받았을 때 여기서 지정한 user와 group으로
응답을 하게된다. 이 설정은 ServerType이 Standalone방식이며, 아파치의
실행이 root권한으로 실행이 되었을 때 유효한 것이다. 많은
웹서버관리자들이 nobody로 설정을 해 두고 있으며, 만약 시스템에 nobody
user가 없다면 새로생성(useradd)을 해야 할 것이다. 단, root로 설정하는
것은 절대로 있어서는 안되며 nobody이외의 다른 시스템사용자 id로 지정을
한다면 정말 신중히 모든면(시스템 보안 및 자원사용등)에서 깊게 고려를
해봐야 한다.


여기서 지정하는 email address는 웹문서 로딩에러등의 문제에서
클라이언트측으로 보내질 메일주소값이다. 대부분
웹서버관리자의 email address로 설정을 한다.


클라이언트에게 보여주는 호스트이름을 지정한다. www를 쓰지않는
호스트에서 www를 쓰는 것처럼 보이게 할 수 있다. 예를 들어을로 지정해서 쓸 수 있다.
이곳에 IP Address를 적게 되면 클라이언트에는 Ip Address를 보여준다.

DocumentRoot "/usr/local/apache/htdocs"

아파치 웹서버의 웹문서가 있는 경로를 지정한다. 예를 들어
""의 초기 문서라면 이 초기문서의
절대 경로는 여기서 지정된 "/usr/local/apache/htdocs/index.html"이 된다.
경로의 맨 마지막에 "/"를 추가해서는 안된다. Alias를 사용하여 다른 위치를
지정할 수도 있다.

<Directory />
Options FollowSymLinks
AllowOverride None

<Directory>에서 지정되는 값에 대한 옵션은 다음과 같은 의미를 가지고
None : 일단 모든허용을 하지 않는다.
All : 모든허용을 한다.
Indexes :
Includes :
FollowSymlinks :
ExeCGI :
MultiViews :

UserDir public_html

하나의 아파치 웹서버에서 여러 사용자의 홈페이지를 별도로 만들어
관리할 때 필요한 개별 가입자의 홈페이지 디렉토리이름이다. 예를 들어
sspark이란 계정가입자의홈페이지는 ""라는
홈페이지를 가지고 있을 때 sspark의 계정에서 "public_html"이란
디렉토리가 홈디렉토리가 되어 이 디렉토리에 있는 초기문서 index.html을
불러서 보여주게 된다.

<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch
Order allow,deny
Allow from all
Order deny,allow
Deny from all

계정사용자의 홈페이지(public_html)의 접근에 대한 옵션을 지정한 것이다.

DirectoryIndex index.html

디렉토리만을 지정했을 경우에 그 디렉토리에서 찾게될 문서의 순서를
지정해 준다. 즉, 디렉토리 이름만을 지정하더라도 여기서 지정한
index.html을 찾아서 웹브라우즈에 보여준다. 여러개의 파일을 지정할 수
있으며, 이런 경우에는 순서대로 찾아서 보여준다. 예를 들어
"DirectoryIndex index.html index.htm"로 지정했다면 먼저 "index.html"을
찾아서 있다면 이 파일을 로딩하고, "index.html"이 없다면 "index.htm"을
찾아서 로딩해 준다.

AccessFileName .htaccess

디렉토리별로 접근제어할 정보(ID, Password)를 담고 있는 파일을
지정한다. 디렉토리별로 인증을 거쳐서 접근할 수 있는 설정을 하기위한
것이다. 예를 든다면 어떤 홈페이지의 전부나 혹은 일부에로 접근하려고 할
때 ID, Password를 묻는 창이 뜨면서 맞게 입력한 경우에만 접근허용하는
것이다. 보안상의 이유로 이 파일의 이름을 다른 이름으로 바꾸로 싶다면
".htaccess"대신에 다름이름을 적어주면 된다.

<Files ~ "^.ht">
Order allow,deny
Deny from all

바로위에서 설정한 파일(".htaccess")의 내용을 볼 수 없게 할 때 사용하는
옵션이다. 보안상의 이유로 이 옵션은 설정해 두는 것이 좋다. 만약 이
옵션을 주석처리해 둔다면 ".htaccess"파일에 대한 보안은 누구도 장담할 수
없을 것이다.

UseCanonicalName On

TypesConfig conf/mime.types

웹서버의 mime type을 지정한 파일을 지정한다. mime.types파일은 서버에
의해 리턴될 수 있는 파일명과 mime형식을 기술해 놓은 파일이다.

DefaultType text/plain

mime.types 파일에 정의 되어있지 않은 파일형식에 대한 요청을 받았을 때
알 수 없는 문서타입에 대하여 사용할 기본적인 mime 타입을 정해둔다.

HostnameLookups Off

웹서버의 로그(access_log)를 지정하는 Format에서 "DNS Lookup"으로
지정하였을 때, domain으로 남길 것인가, IP Address로 남길 것인가를
지정한다. Default로 Off는 IP Address로 남기는 것이며, Domain으로 변경할
필요가 없으므로 on으로 설정한 것보다는 속도가 조금빠르다.on으로 하게
되면 IP address를 IP Domain으로 변환해야 하므로 속도가 조금 느릴 수

ErrorLog logs/error_log

아파치 웹서버의 에러로그 기록파일을 지정한다. 참고할 사항은 맨
마지막에 설정하는 <VirtualHost>부분에서 각서버에 대한 에러파일을
지정해 두지 않으면 그에 대한 에러로그도 여기에 기록되며, 지정해 두게
되면 그에 해당하는 로그는 이 파일에 기록되지 않는다.

LogLevel warn

바로위에서 설정한 에러로그 파일에 얼마나 자세하게 적을 것인지를
결정한다. 다음에 해당하는 순서대로 중요도가 정해진다. " debug → info →
notice → warn → error → crit → alert → emerg "

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i"
"%{User-Agent}i"" combind
LogFormat "%h %l %u %t "%r" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

바로 아래에서 사용할 CustomLog에서 사용할 몇가지 로그형식의 별명을
정한 곳이다.
웹서버의 관리자나 서버관리자는 이 부분을 특히 유심히 봐둬야 한다.
웹서버의 로그를 어떤 식으로 남길 것인가를 결정하는 Format을 지정하는
곳이다. 원하는 정보를 지정해서 볼 수 있으므로, 관리자에게 필요한
Format으로 설정해야 하며, 또한 접속통계를 내기에 적당한 Format으로
설정해 둬야 한다.

CustomLog logs/access_log common

위에서 정한 로그형식(여기선 common)대로 로그를 남기게 된다.
맨마지막에서 지정하는 <VirtualHost>부분에서도 아파치 1.3.9버전 부터는
CustomLog를 가상호스트별로 지정할수 있도록 CustomLog를 제공한다.
<VirtualHost>에서 CustomLog를 지정하지 않으면 여기서 지정한 형식대로
로그를 남기게 되며 <VirtualHost>부분에서 CustomLog를 지정했을
경우에는 여기서 지정한 로그형식은 무시된다.

#CustomLog logs/referer_log referer
#CustomLog logs/agent_log agent
#CustomLog logs/access_log combined

위에서 지정한 4가지의 로그형식(combind, common, referer, agent)중에서
원하는 부분의 #(주석행)을 제거하면 지정된다.

ServerSignature On

서버가 생성하는 문서(error documents, FTP directory listings,
mod_status and mod_info output etc., but not CGI generated documents)의
trailing footer line의 설정을 가능하게 한다.

Alias /icons/ "/usr/local/apache/icons/"

필요한 만큼의 디렉토리 별칭을 만들어 쓸 수 있다. 사용하는 형식은
다음과 같다.
Alias fakename(가상이름) realname(진짜이름)

ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"

ScriptAlias는 서버스크립트를 포함한다. ScriptAlias는 실제디렉토리 안에
들어있는 문서를 서버에 의해 응용프로그램으로 취급되어 실행되는 것을
제외하고는 근본적으로 Aliases와 같다.

IndexOptions FancyIndexing

IndexOPtions는 디렉토리목록을 표시할 때 사용할 옵션을 지정한다.
Standard는 표준적인 디렉토리를 나타내며, FancyIndexing은 좀더 예쁜
디렉토리목록을 표시해 준다.

아래에서 지정하는 AddIcon으로 시작하는 설정은 바로위에서 설정한
디렉토리인덱싱 옵션을 FancyIndexing으로 한 경우에 해당하며 디렉토리
목록을 표시할 때 각 파일 확장자에 따라서 어떤 아이콘을 선택하여 보여줄
것인지를 지정한다.

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

DefaultIcon /icons/unknown.gif

여기서 지정한 확장가가 아닌 경우에 여기서 지정한 기본아이콘으로

AddDescription "GZIP compressed document" .gz
AddDescription "tar archive" .tar
AddDescription "GZIP compressed tar archive" .tgz

AddDescription은 서버가 생성한 인덱스의 파일 뒤에 간단한 설명을
표시할 때 사용한다. 이 설정은 IndexOptions가 FancyIndexing으로
설정되었을때만 표시되며, 설정형식은 다음과 같다.
형식 : AddDescription "표시할 설명" 파일확장자

ReadmeName README

ReadmeName은 디렉토리목록표시 뒤에 붙여서 보여줄 README파일의
이름을 지정한다.(일종의 꼬릿말)

HeaderName HEADER

HeaderName은 디렉토리목록표시 앞에 붙여질 파일의 이름을 지정한다.
(일종의 머릿말)

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

디렉토리목록을 인덱싱할 때 제외할 파일명을 지정한다. 즉 디렉토리
목록에 포함하지 않을 파일을 지정한다. 쉘스타일의 와일드카드(*, ?)가

AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

AddEncoding은 특정브라우즈(Mosaic/X 2.1+)에서 받고있는 중에 정보에
대한 압축해제를 할 수 있도록한다. 단 모든 웹브라우즈에서 이 기능을
제공하는 것은 아니다.

AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it

AddLanguage는 문서의 언어를 지정하게 한다.

LanguagePriority en fr de

언어의 우선순위를 내림차순으로 지정한다.

AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
AddType application/x-tar .tgz

AddType은 mime.types의 실제 편집없이도 mime을 설정할 수 있다.

AddHandler cgi-script .cgi

AddHandler는 파일확장자를 처리기(Handler)에 매핑(연결)시켜주게 된다.

AddType text/html .shtml
AddHandler server-parsed .shtml

SSI(Server Side Include)문서를 인식하게 하기위한 설정이다. SSI코드가
들어가 있는 문서는 확장자가 *.shtml이다. 시스템의 날짜와 카운터등
CGI프로그램을 하지 않아도 HTML문서에서 단 몇줄로 CGI의 효과를 낼 수
있는 SSI기능을 인식하게끔 하는 설정이다. "7장. 아파치와 SSI"편에서 자세히
설명되어 있다.

#Format: Action media/type /cgi-script/location
#Format: Action handler-name /cgi-script/location

Action은 매칭되는 파일이 호출될때마다 스크립트를 실행시킬 수 있도록
미디어 타입을 정의한다.

MetaDir .web

MetaDir은 아파치가 찾을 메타정보파일들의 디렉토리이름을 지정한다. 이
파일들은 문서를 전송할 때 포함되는 HTTP 헤더정보가 포함되어 있다.

MetaSuffix .meta

MetaSuffix는 메타정보를 포함하고 있는 접미어의 이름을 지정한다.

에러발생시 응답을 정의할 수 있는 방법을 3가지 나타내고 있다.

1) 일반적인 텍스트

ErrorDocument 500 "The server made a boo boo.

2) 지역적인 방향전환

ErrorDocument 404 /missing.html
ErrorDocument 404 /cgi-bin/

3) 외부 방향전환

ErrorDocument 402

다음의 BrowserMatch는 keepalives기능을 쓰지못하게 하며 HTTP
헤드방식을 설정한다.

BrowserMatch "Mozilla/2" nokeepalive

이 설정은 Netscape 2.x 또는 이를 따르는 브라우즈에 대하여 KeepAlive
기능을 쓰지 못하게한다.

BrowserMatch "MSIE 4.0b2;" nokeepalive downgrade-1.0

이 설정은 잘못구현된 HTTP/1.1과 301또는 302반응에 대하여
KeepAlive를 적절히 제공하지 못하는 마이크로소프트 인터넷익스플로러
4.0b2d에 관한 것이다.

BrowserMatch "RealPlayer 4.0" force-response-1.0
BrowserMatch "Java/1.0" force-response-1.0
BrowserMatch "JDK/1.0" force-response-1.0

위의 3가지 설정은 기본적인 1.1반응도 처리하지 못하며 HTTP/1.0 스팩을
제한하고 있는 브라우즈에 대하여 HTTP/1.1반응을 하지 못하게 한 것이다.

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from

서버의 상태를 점검할 수 있게하는 설정이다. 이는
""와 같은 형식으로 서버의 상태를
점검할 수 있다. "6장. 아파치서버 모니터링"편에서 자세히 설명되어 있다.
여기서 지정한 "SetHandler server-status"의 설정으로 인해 서버
모니터링을 할 수 있는 것이다.

<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from

이설정을 위해서는 mod_info.c가 적재되어야 하며, 이는
""와 같은 방식으로 서버의 정보를
볼 수 있다. 위에서 설정한 server-status와 함께 실행중인 웹서버의
상태점검을 위한 것이다.

<Location /cgi-bin/phf*>
Deny from all
ErrorDocument 403

아파치 1.1이전 버전의 오래된 버그에 대한 악용이 있을시에는 지정한곳
( 으로 방향을 전환시킨다.

<IfModule mod_proxy.c>
ProxyRequests On

아파치 웹서버를 Proxy서버로 사용할 때 on을 해줘야 한다. 즉
프락시서버 지시자로서 프락시서버를 on 시킨다.

<Directory proxy:*>
Order deny,allow
Deny from all
Allow from

ProxyVia On

HTTP/1.1 "Via:"헤드처리를 활성화시킬 것인지 비활성화 시킬것인지를
지정한다. Off, On, Full, Block중 하나가 올 수 있으며 Full은 서버버전을
포함하며, Block은 나가는 모든 것에 대해 Via:헤더를 제거한다.

CacheRoot "/usr/local/apache/proxy"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1

이 설정은 캐시기능을 활성화 하기 위한 것이다.

### Section 3: 가상호스트 설정

여러분의 시스템에서 여러개의 도메인이나 호스트네임을 설정하여
관리하고자 한다면 <VirtualHost>부분을 설정해 줘야 한다. 가상호스트에
대한 정보는를 참조해 보면 좀더
자세한 정보를 얻을 수 있다. '-S'옵션을 사용함으로써 가상호스트의 설정에
대한 점검을 할 수 있다. name-based 가상호스트를 사용하길 원한다면
적어도 한 개이상의 IP Address를 정의할 필요가 있다. "4-2절의 내용"과
"10장.웹호스팅 서비스를 위한 가상호스트"편에서 자세히 설명되어 있다.


DocumentRoot /home/sspark/public_html
ErrorLog /home/sspark/public_html/aw/error_log
CustomLog /home/sspark/public_html/aw/access_log common

ServerAdmin은 해당서버의 관리자 전자우편이며,
DocumemtRoot는 해당서버의 홈디렉토리이며,
ServerName은 해당서버의 도메인이며,
ErrorLog는 해당서버의 에러파일 위치이며
CustomLog는 로그파일위치와 포맷을 지정한 것이다.

<VirtualHost _default_:*>

Default 가상호스트 설정으로 위에서 설정되지 않은 다른 모든 호스트에
대해서 응답을 하고자 할 경우설정해 준다.


2006/09/11 10:21 2006/09/11 10:21
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 서른하나...새로운 시작

1.vi편집기로 아래와 같은 스크립트를 만듭니다.

[root@op root]# vi
DATE=`/bin/date +%y%m%d`
/bin/cp /usr/local/apache/logs/access_log /usr/local/apache/logs/access_log.$DATE
cat /dev/null > /usr/local/apache/logs/access_log
/bin/gzip /usr/local/apache/logs/access_log.$DATE
/bin/cp /usr/local/apache/logs/error_log /usr/local/apache/logs/error_log.$DATE
cat /dev/null > /usr/local/apache/logs/error_log
/bin/gzip /usr/local/apache/logs/error_log.$DATE
위의 아파치 로그 경로는 실제 아파치 로그가 있는 경로로 설정해주면 됩니다.
예를 들어 /var/log/httpd/에 로그파일을 옮겼다면 모든 경로를
/var/log/httpd로 바꿔놓으면 됩니다.

2.다음과 같이 실행 가능한 파일로 변경 합니다.
[root@op root]# chmod 755

3.위의 스크립트를 clontab에 넣어서 매일 실행하게 합니다.
[root@op root]# crontab -e
0 3 * * * /root/
스크립트가 있는 경로를 등록해주시면 되고 매일 3시에 돌게 되어있습니다.

4.스크립트가 실행되어 로그가 일자별로 압축되어 저장된 결과입니다.
[root@op root]# cd /usr/local/apache/logs/
[root@op logs]# ls
access_log access_log.031031.gz error_log error_log.031031.gz
로그체크를 할때 필요한 날짜의 로그만 압축을 풀어서 확인하시면 되겠죠?

위의 스크립트를 응용하면 아파치 로그뿐만 아니라 /var/log 아래
있는 여러 로그들을 일별로 효율적으로 관리할 수 있습니다.

* 출처 :

2006/09/11 10:21 2006/09/11 10:21
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > Technology Evangelist를 꿈꾸며.
브라우징 제거아파치의 디폴트세팅은 브라우징이 enable되어 있다.브라우징이란 웹브라우저에서 URL입력시 index.html과 같은 정확한 파일명을생략하고 디렉토리만 적었을 경우, 디렉토리내 파일목록이 출력되는 현상을 말한다.http.conf의 디렉토리 디렉티브내 다음줄 추가Options -Indexes아파치 인증창 사용http.conf에서 인증을 걸 디렉토리 디렉티브내 다음줄 추가    AllowOverride AuthConfig해당 디렉토리에 다음과 같이 .htaccess파일(텍스트파일) 생성[root@ns mrtg]# cat .htaccess AuthName "MRTG를 위한 인증"AuthType BasicAuthUserFile /webhosting/mrtg/.authrequire valid-userAuthName: 인증창 타이틀AuthType: 인증형태AuthUserFile: 인증자들의 리스트를 가진 파일(htpasswd명령어로 생성)-c(create)는 처음 파일을 생성할때 필요하다.[root@ns mrtg]# htpasswd -c .auth kang New password: Re-type new password: Adding password for user kang[root@ns mrtg]# ls -l .auth-rw-r--r--    1 root     root           19 May  3 16:54 .auth외부 IP접근제어http.conf의 디렉토리 디렉티브내 다음줄 추가	AllowOverride AuthConfig    Order Allow,Deny    Deny from    Allow from all    Deny from 에 접근차단할 ip대를 입력.슬래쉬(/)뒤의 숫자들은 net mask지정(생략하면 single ip에 대한 차단)위의 내용을 종합한 예는 다음과 같다.        Options -Indexes FollowSymLinks MultiViews    AllowOverride AuthConfig    Order allow,deny    Allow from all    Deny from가상호스트/Redirect아래의 예는로 오면,로 redirect시킨다.본인은 아파치말고, packet filtering으로 처리하려했으나 실력부족과 게으름으로 인해그만두었다.    ServerName    Redirect    /가상호스트의 전형적인예    ServerAdmin    DocumentRoot        /webhosting/dbakorea-mobile    ServerName    ErrorLog            /usr/local/apache/logs/    CustomLog           /usr/local/apache/logs/ common    ScriptAlias /cgi-bin/ /webhosting/dbakorea-mobile/cgi-bin/	DirectoryIndex      login.html아파치 정보출력제어80포트로 telnet후 get / http/1.0하면 나오는 정보제어ServerTokens Prod[uctOnly] : Apache 만 보여줌 ServerTokens Min[imal] : Apache 버젼만 보여줌 ServerTokens OS : 아파치 버젼과 운영체제를 보여줌 ServerTokens Full (또는 지시하지 않았을때) : 모두 보여줌Offline Browser서비스 거부(출처:만 테스트해봤지만 %{User-agent} 라는 변수에 'MSIE 6.0b'와 같이 찍힌다.한마디로 안된다. 다른 용도로 사용될 지 몰라도,..<Directory />    Options FollowSymLinks    AllowOverride None    Order allow,deny    Allow from all    Deny from env=go_out</Directory>#CustomLog /usr/local/apache/logs/access_log common#CustomLog /usr/local/apache/logs/referer_log referer#CustomLog /usr/local/apache/logs/agent_log agentCustomLog /usr/local/apache/logs/access_log combined<IfModule mod_setenvif.c>    BrowserMatch "Mozilla/2" nokeepalive    BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0    BrowserMatch "RealPlayer 4\.0" force-response-1.0    BrowserMatch "Java/1\.0" force-response-1.0    BrowserMatch "JDK/1\.0" force-response-1.0    BrowserMatch "WebZIP" go_out    BrowserMatch "Teleport" go_out    BrowserMatch "GetRight" go_out    BrowserMatch "WebCopier" go_out</IfModule><VirtualHost *>     ServerAdmin     DocumentRoot        /webhosting/dbakorea     ServerName     ServerAlias     ErrorLog            /usr/local/apache/logs/     CustomLog           /usr/local/apache/logs/ combined</VirtualHost>아파치 로그 rotate디폴트로 아파치로그는 wtmp, lastlog등과 같이 일정 시간, 크기..등등에 따라 로그의 순환이 
이루어지지 않는다.logrotate로 3개의 로그를 1달단위로 순환하려면 /etc/logrotate.conf파일의 마지막에 다음과 같이 추가한다.# system-specific logs may be configured here/usr/local/apache/log/ { monthly rotate 2}바이러스등에 대한 아파치로그 제거# CodeRed Worm등의 로그제거SetEnvIf Request_URI default\.ida CodeRedSetEnvIf Referer \.ida CodeRedSetEnvIf Request_URI cmd\.exe CodeRedSetEnvIf Referer cmd\.exe CodeRed SetEnvIf Request_URI root\.exe CodeRedSetEnvIf Referer root\.exe CodeRed ServerAdmin DocumentRoot /webhosting/dbakorea ServerName ServerAlias ErrorLog /usr/local/apache/logs/ CustomLog /usr/local/apache/logs/ combined env=!CodeRe
2006/09/11 10:20 2006/09/11 10:20
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > No.0

출처 :

        (원본에서 몇몇 수정 하였음)

Apache Rewrite Module -작성자 : 윤일-

Apache 는 추가적으로 사용할 수 있는 유용한 모듈들을 제공합니다.

이번강좌에서는 Apache의 URL Rewrite 모듈을 사용하기 위한 컴파일,설치 와 httpd.conf의

설정방법 그리고 활용방법에 대해 알아보겠습니다.

Apache 다운로드 :

1. rewrite 모듈을 사용하기 위한 Apache 컴파일옵션
[옵션] : --enable-rewrite

[설명] : Rewrite 모듈을 쓰기위한 Apache 컴파일 옵션은 --enable-rewrite 입니다.

            Configure 실행시에  --enable-rewrite 만 추가하시면 Apache에서 rewrite 모듈을

            사용할 있게 됩니다.

          [root@superuser root]# ./cofigure prefix=/usr/local/apache2 --enable-rewrite
          [root@superuser root]# make
          [root@superuser root]# make install

1. Rewrite 를 적용할 수 있는 범위
Rewrite 설정은 Server Config, Virtual Host, Directory, .htaccess 에 설정할 수 있습니다.

즉, Apache 서버 전체에 Global 설정과 특정 가상호스트에만 적용하도록 할수 있고 특정 디렉토리

에만 적용시킬수도 있습니다.

2. Rewrite 모듈 지시자

[문법] : RewriteEngine On 또는 Off
[설명] : Rewriteing 엔진을 사용할지 여부를 설정합니다. 기본설정은 당연히 Off로 되어 있으며

            RewriteEngine On 으로 설정하지 않는 이상 Rewritng 엔진을 활성화 시키지 않습니다.
[기타] : 현재 Apache에서 실행중인 모든 RewriteRule을 비활성화 시킬 때 RewriteRule 라인을

           주석처리 하기보다 RewriteEngin Off 로 설정하는 것이 더 간편하고 올바른방법입니다.


[문법] : RewriteLog FILE-PATH
[설명] : RewriteLog 지시자는 Rewrite 엔진의 로그를 그록할 파일을 지정합니다.

            RewriteLog 파일을 항상 남기기 보다 잘못된 Rewrite 규칙들을 디버킹할 때 사용하기를

            권장합니다. 아파치와 마찬가지로 RewriteLog 파일도 방문자수가 많은사이트에서는

            감당못할 정도의 로그파일을 남기기 때문에 시스템 여유공간이 많이 없는 시스템에서는

            해당 파티션의 하드사용률 100%로 인한 재앙(?)을 불러올수도 있습니다.

[조건] : RewriteLog 지시자는 반드시 RewriteLogLevel 지시자와 함께 사용하여야 됩니다.


[문법] : RewriteLogLevel Level
[설명] : RewriteLogLevel 지시자는 RewriteLog 지시자로 설정한 로그파일에 기록할 로그들에

            대해 얼마나 자세한 내용을 로그로 남길것인가에 대해 설정하는 지시자입니다.
            기록할 로그 Level 은 0~9까지 사용할 수 있으며 0은 로그를 기록하지 않겠다는

            의미입니다. Level 숫자가 높을수록 자세한 로그를 기록합니다


[문법] : RewriteCond TestStirng CondPattern

[설명] : RewriteCond 지시자는 RewriteRule 과 함께 사용되는 규칙으로 RewriteCond 다음에

            오는 RewriteRule은 RewrieteCond 에서 설정한 패턴과 일치해야지만 RewriteRule들을



[문법] : RewriteRule Pattern Substitution
[설명] : Rewrite 모듈의 실질적인 Rewrite 규칙들을 적용하는 지시자입니다.

            Pattern(Input URL) 을 Subtitution(Return URL)로 변경하기 위한 모든 규칙들은 이

            지시자를 사용해서 설정해야 됩니다.
[기타] : Pattern(Input URL) 에는 Perl 정규표현식을 사용할수 있기 때문에 Input URL 의 규칙을

            유연하게 적용할 수 있습니다.

[표1] : 정규표현식 기초


다수의 한문자


0개 이상의 한문자


0개 이상의 문자 또는 문자열


1개 이상의 문자 또는 문자열


(, ) 안의 문자또는 문자열을 그룹으로 묶습니다.

이 문자그룹은 Substitution(return URL)에서 $N 의 변수로

활용할수 있습니니다.


문자열의 첫문(열)을 지정합니다.


문자열의 끝 문자(열)을 지정합니다.


정규표현식에서 특별한 의미로 사용되는 문자의 특수기능을

제거합니다.(예:(, ), [, ] . 등)


정확히 n번 반복


n번 이상 반복


n 이상 m 이하 반복


문자들의 범위 또는 표현할 수 있는 문자들을 설정합니다.

예) [a-z] : a 부터 z 까지의 소문자, [tT] : 소문자 t 또는 대문자 T

[표2] : 정규표현식 단축표현들


알파벳. [a-zA-Z] 와 같은 표현


알파벳과 숫자. [a-zA-Z0-9] 와 같은 표현


숫자 [0-9] 와 같은 표현


대문자. [A-Z] 와 같은 표현

RewriteRule 플래그

[설명] : 요청하는 페이지를 403 에러로 redirect 시킵니다. RedirectRule 이 적용되고 있는

            페이지를 일시적으로 사용중단을 시키거나 사용자로 하여금 페이지 접근을 할수 없게

            할 때 사용합니다.
[예제] : RewriteRule ^/test /home/blog/html/test.php [F]
            사용자가 /test 로 접근할 경우 403 에러를 보냅니다.


[설명] : 요청하는 페이지를 410 에러로 redirect 시킵니다. 410 에러는 페이지가 사라젔거나

            존재하지 않는다는 메시지입니다. 이것도 forbidden 과 마찬가지로 RedirectRule 이

            적용되던 페이지를 일시적으로 중단시킬 때 유용하게 사용할 수 있습니다.


[설명] : 이 플래그가 적용되면 뒤에 어떤 룰이 있더라도 이룰 아래의 규칙들은 적용되지 않고

            RewriteRule 을 빠져나가게 됩니다. C, Perl, PHP 프로그램에서 루프를 빠져나가는

            break 와 같은 의미를 가집니다.

[설명] : 이 플래그의 결과를 다음 RewriteRule 의 input 값으로 사용합니다.

[기타] : 이 룰은 사용자 홈의 도메인을 2차 도메인으로 자동설정해 줄 때 많이 쓰는 룰입니다.

            RewriteRule의 input은 도메인을 제외한 URI 를 인식하기 때문에 도메인까지 인식을 시켜

            서 다음 RewriteRule 로 체크를 하기 위해 사용한 것입니다.

            즉, 이란 요청이 들어오면

            /home/user_id/public_html/hello.html 로 redirect 시켜줍니다. 위와 같이 2차 도메인을

            이용해 계정 사용자의 홈을 지정하기 위해서는 DNS 세팅이 선행되어야 됩니다.

[예제1] : RewriteRule ^(.+) %{HTTP_HOST}$1 [C]

             RewriteRule ^([^.]+)\.domain\.com(.*) /home/$1/public_html$2

[예제2] : RwriteRule 설정예

   1.  ->

      RewriteRule ^/([a-zA-Z0-9])$   /home/user_id/public_html/home.php?id=$1

      설명 : 도메인( 뒤에 오는 영문숫자로된 문자열을 지정하면서 그룹으

               로 묶었습니다. 이렇게 그룹으로 설정된 문자열 Pattern 은 Substitution(return URL)

               에서 $1 이라는 변수로 받아 사용하게 됩니다. 즉

               라는 페이지 요청이 들어오면 실제로는

      라는 페이지로 redirect 시켜줍니다.

               블로그나 카페(동호회) 사이트에서 블로그 사용자의 ID 로 개인 블로그 주소를 부여할

               때 로 부여해 주지만 실제 실행되는 파일은 이와 같이

               redirect 시켜주는 경우가 많습니다.

   2.  ->
      RewriteRule ^/daum$  ->

       [설명] : 라는 페이지 요청이 들어오면 도메인이 다른

          이라는 페이지로 redirect 시켜줍니다.


[문법] : RewriteOptions Options
[설명] : 현재 사용할 수 있는 option 은 MaxRedirects=number 를 사용할 수 있으며 설정된

            number값에 도달하게 되면 500 Internal Server Error 를 남기고 RewriteRule을 종료합니

            다. 잘못된 RewriteRule에 의한 무한 루프를 방지하기 위한 목적으로 사용되는데 시스템

            이 이유없이 다운된다거나 할 때 이 옵션과 Log 기록을 참고하여 디버깅 및 시스템 다운

            을 방지할 수 있습니다. 이 지사자는 Apache 2.0.45 이상에서 사용할 수 있습니다.

3. 실제 적용예
가상호스트 에 대해 Rewrite Rule을 적용한 예입니다. 이 부분은 실제 운영

되는 블로그 사이트를 위해 RewriteRule 을 적용한 예입니다.

DocumentRoot      /home/blog/html

# 여기까지는 일반적인 가상호스트 설정입니다.

RewriteEngine      on
# RewriteRule을 사용하기 위해 On 으로 설정합니다.

RewriteLog          /home/blog/rewrite_log_admin3.log
RewriteLogLevel   9
# Rewrite 실행중 Log를 남기기 위해 로그파일과 로그레벨을 지정했습니다.

RewriteRule         ^/tb/([a-zA-Z0-9]+)/([0-9]+)$ /home/blog/html/blog/trackback.php?id=$1&post_no=$2

# 위설정은 블로그에 등록된 포스트의 트랙백 주소를 부여하기 위해 설정한 RewriteRule 로써 Pattern에 두개의 그룹이 존재하고 return URL에 순서대로 각 그룹을 $1 과 $2 로 받아 GET 변수로 치환한것입니다.

RewriteRule         ^/xml/([a-zA-Z0-9]+)$ /home/blog/html/blog/rss_feed.php?id=$1
# 각블로그별 RSS 주소를 실제 파일로 지정한것입니다.

RewriteCond        %{REQUEST_URI}     !^/admin$
RewriteRule         ^/([a-zA-Z0-9]+)$ /home/blog/html/blog/main.php?id=$1
# 먼저 RewriteCond 로 실제 존재하는 admin 이라는 디렉토리를 이어지는 RewriteRule에서 제외시키고 로의 요청을 모두 /home/blog/html/blog/main.php?id=user_id로 redirect 시키는 룰입니다.

RewriteRule ^/([a-zA-Z0-9]+)/([0-9]+)$ /home/blog/html/blog/main.php?id=$1&post_no=$2
# /user_id/1345 로 요청하는 페이지를 /home/blog/html/blog/main.php?id=user_id&post_no=1345 로 redirect 시키는 룰입니다.

4. 마치면서
위에서 언급한 RewriteRule 뿐만 아니라 여러가지 상황에서 RewriteRule을 잘 활용한다면 아주 유용하게 웹페이지를 컨트롤 할수 있습니다. RewriteRule 을 세팅하기 이전에 반드시 정규표헌식에 대해 어느정도 공부한후 적용해 보실 것을 권합니다.



Apache HTTP Server Version 1.3

Is this the version you want? For more recent versions, check our documentation index.

Module mod_rewrite
URL Rewriting Engine

This module provides a rule-based rewriting engine to rewrite requested URLs on the fly.

Status: Extension
Source File: mod_rewrite.c
Module Identifier: rewrite_module
Compatibility: Available in Apache 1.2 and later.


``The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.''
-- Brian Behlendorf
Apache Group
`` Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. ''
-- Brian Moore
Welcome to mod_rewrite, the Swiss Army Knife of URL manipulation!

This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, for instance server variables, environment variables, HTTP headers, time stamps and even external database lookups in various formats can be used to achieve a really granular URL matching.

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can even generate query-string parts on result. The rewritten result can lead to internal sub-processing, external request redirection or even to an internal proxy throughput.

But all this functionality and flexibility has its drawback: complexity. So don't expect to understand this entire module in just one day.

This module was invented and originally written in April 1996
and gifted exclusively to the The Apache Group in July 1997 by

Ralf S. Engelschall

Table Of Contents

Internal Processing

Configuration Directives


Internal Processing

The internal processing of this module is very complex but needs to be explained once even to the average user to avoid common mistakes and to let you exploit its full functionality.

API Phases

First you have to understand that when Apache processes a HTTP request it does this in phases. A hook for each of these phases is provided by the Apache API. Mod_rewrite uses two of these hooks: the URL-to-filename translation hook which is used after the HTTP request has been read but before any authorization starts and the Fixup hook which is triggered after the authorization phases and after the per-directory config files (.htaccess) have been read, but before the content handler is activated.

So, after a request comes in and Apache has determined the corresponding server (or virtual server) the rewriting engine starts processing of all mod_rewrite directives from the per-server configuration in the URL-to-filename phase. A few steps later when the final data directories are found, the per-directory configuration directives of mod_rewrite are triggered in the Fixup phase. In both situations mod_rewrite rewrites URLs either to new URLs or to filenames, although there is no obvious distinction between them. This is a usage of the API which was not intended to be this way when the API was designed, but as of Apache 1.x this is the only way mod_rewrite can operate. To make this point more clear remember the following two points:

  1. Although mod_rewrite rewrites URLs to URLs, URLs to filenames and even filenames to filenames, the API currently provides only a URL-to-filename hook. In Apache 2.0 the two missing hooks will be added to make the processing more clear. But this point has no drawbacks for the user, it is just a fact which should be remembered: Apache does more in the URL-to-filename hook than the API intends for it.
  2. Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.

    Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.

Don't forget these two points!

Ruleset Processing

Now when mod_rewrite is triggered in these two API phases, it reads the configured rulesets from its configuration structure (which itself was either created on startup for per-server context or during the directory walk of the Apache kernel for per-directory context). Then the URL rewriting engine is started with the contained ruleset (one or more rules together with their conditions). The operation of the URL rewriting engine itself is exactly the same for both configuration contexts. Only the final result processing is different.

The order of rules in the ruleset is important because the rewriting engine processes them in a special (and not very obvious) order. The rule is this: The rewriting engine loops through the ruleset rule by rule (RewriteRule directives) and when a particular rule matches it optionally loops through existing corresponding conditions (RewriteCond directives). For historical reasons the conditions are given first, and so the control flow is a little bit long-winded. See Figure 1 for more details.

Figure 1: The control flow through the rewriting ruleset

As you can see, first the URL is matched against the Pattern of each rule. When it fails mod_rewrite immediately stops processing this rule and continues with the next rule. If the Pattern matches, mod_rewrite looks for corresponding rule conditions. If none are present, it just substitutes the URL with a new value which is constructed from the string Substitution and goes on with its rule-looping. But if conditions exist, it starts an inner loop for processing them in the order that they are listed. For conditions the logic is different: we don't match a pattern against the current URL. Instead we first create a string TestString by expanding variables, back-references, map lookups, etc. and then we try to match CondPattern against it. If the pattern doesn't match, the complete set of conditions and the corresponding rule fails. If the pattern matches, then the next condition is processed until no more conditions are available. If all conditions match, processing is continued with the substitution of the URL with Substitution.

Quoting Special Characters

As of Apache 1.3.20, special characters in TestString and Substitution strings can be escaped (that is, treated as normal characters without their usual special meaning) by prefixing them with a slosh ('\') character. In other words, you can include an actual dollar-sign character in a Substitution string by using '\$'; this keeps mod_rewrite from trying to treat it as a backreference.

Regex Back-Reference Availability

One important thing here has to be remembered: Whenever you use parentheses in Pattern or in one of the CondPattern, back-references are internally created which can be used with the strings $N and %N (see below). These are available for creating the strings Substitution and TestString. Figure 2 shows to which locations the back-references are transfered for expansion.
[Needs graphics capability to display]
Figure 2: The back-reference flow through a rule

We know this was a crash course on mod_rewrite's internal processing. But you will benefit from this knowledge when reading the following documentation of the available directives.

Configuration Directives


Syntax: RewriteEngine on|off
Default: RewriteEngine off
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

The RewriteEngine directive enables or disables the runtime rewriting engine. If it is set to off this module does no runtime processing at all. It does not even update the SCRIPT_URx environment variables.

Use this directive to disable the module instead of commenting out all the RewriteRule directives!

Note that, by default, rewrite configurations are not inherited. This means that you need to have a RewriteEngine on directive for each virtual host in which you wish to use it.


Syntax: RewriteOptions Option
Default: RewriteOptions MaxRedirects=10
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2; MaxRedirects is available in Apache 1.3.28 and later

The RewriteOptions directive sets some special options for the current per-server or per-directory configuration. The Option strings can be one of the following:

This forces the current configuration to inherit the configuration of the parent. In per-virtual-server context this means that the maps, conditions and rules of the main server are inherited. In per-directory context this means that conditions and rules of the parent directory's .htaccess configuration are inherited.
In order to prevent endless loops of internal redirects issued by per-directory RewriteRules, mod_rewrite aborts the request after reaching a maximum number of such redirects and responds with an 500 Internal Server Error. If you really need more internal redirects than 10 per request, you may increase the default to the desired value.


Syntax: RewriteLog file-path
Default: None
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

The RewriteLog directive sets the name of the file to which the server logs any rewriting actions it performs. If the name does not begin with a slash ('/') then it is assumed to be relative to the Server Root. The directive should occur only once per server config.

Note: To disable the logging of rewriting actions it is not recommended to set file-path to /dev/null, because although the rewriting engine does not then output to a logfile it still creates the logfile output internally. This will slow down the server with no advantage to the administrator! To disable logging either remove or comment out the RewriteLog directive or use RewriteLogLevel 0!
Security: See the Apache Security Tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.


RewriteLog "/usr/local/var/apache/logs/rewrite.log"


Syntax: RewriteLogLevel Level
Default: RewriteLogLevel 0
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

The RewriteLogLevel directive sets the verbosity level of the rewriting logfile. The default level 0 means no logging, while 9 or more means that practically all actions are logged.

To disable the logging of rewriting actions simply set Level to 0. This disables all rewrite action logs.

Notice: Using a high value for Level will slow down your Apache server dramatically! Use the rewriting logfile at a Level greater than 2 only for debugging!


RewriteLogLevel 3


Syntax: RewriteLock file-path
Default: None
Context: server config
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.3

This directive sets the filename for a synchronization lockfile which mod_rewrite needs to communicate with RewriteMap programs. Set this lockfile to a local path (not on a NFS-mounted device) when you want to use a rewriting map-program. It is not required for other types of rewriting maps.


Syntax: RewriteMap MapName MapType:MapSource
Default: not used per default
Context: server config, virtual host
Override: Not applicable
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

The RewriteMap directive defines a Rewriting Map which can be used inside rule substitution strings by the mapping-functions to insert/substitute fields through a key lookup. The source of this lookup can be of various types.

The MapName is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:

${ MapName : LookupKey }
MapName : LookupKey | DefaultValue }
When such a construct occurs the map MapName is consulted and the key LookupKey is looked-up. If the key is found, the map-function construct is substituted by SubstValue. If the key is not found then it is substituted by DefaultValue or by the empty string if no DefaultValue was specified.

The following combinations for MapType and MapSource can be used:

  • Standard Plain Text
    MapType: txt, MapSource: Unix filesystem path to valid regular file

    This is the standard rewriting map feature where the MapSource is a plain ASCII file containing either blank lines, comment lines (starting with a '#' character) or pairs like the following - one per line.

    MatchingKey SubstValue


    ####  map.txt -- rewriting map##Ralf.S.Engelschall    rse   # Bastard Operator From HellMr.Joe.Average        joe   # Mr. Average
    RewriteMap real-to-user txt:/path/to/file/map.txt
  • Randomized Plain Text
    MapType: rnd, MapSource: Unix filesystem path to valid regular file

    This is identical to the Standard Plain Text variant above but with a special post-processing feature: After looking up a value it is parsed according to contained ``|'' characters which have the meaning of ``or''. In other words they indicate a set of alternatives from which the actual returned value is chosen randomly. Although this sounds crazy and useless, it was actually designed for load balancing in a reverse proxy situation where the looked up values are server names. Example:

    ####  map.txt -- rewriting map##static   www1|www2|www3|www4dynamic  www5|www6
    RewriteMap servers rnd:/path/to/file/map.txt
  • Hash File
    MapType: dbm, MapSource: Unix filesystem path to valid regular file

    Here the source is a binary NDBM format file containing the same contents as a Plain Text format file, but in a special representation which is optimized for really fast lookups. You can create such a file with any NDBM tool or with the following Perl script:

    #!/path/to/bin/perl####  txt2dbm -- convert txt map to dbm format##use NDBM_File;use Fcntl;($txtmap, $dbmmap) = @ARGV;open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644) or die "Couldn't create $dbmmap!\n";while (<TXT>) {  next if (/^\s*#/ or /^\s*$/);  $DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);}untie %DB;close(TXT);
    $ txt2dbm map.txt map.db
  • Internal Function
    MapType: int, MapSource: Internal Apache function

    Here the source is an internal Apache function. Currently you cannot create your own, but the following functions already exists:

    • toupper:
      Converts the looked up key to all upper case.
    • tolower:
      Converts the looked up key to all lower case.
    • escape:
      Translates special characters in the looked up key to hex-encodings.
    • unescape:
      Translates hex-encodings in the looked up key back to special characters.
  • External Rewriting Program
    MapType: prg, MapSource: Unix filesystem path to valid regular file

    Here the source is a program, not a map file. To create it you can use the language of your choice, but the result has to be a executable (i.e., either object-code or a script with the magic cookie trick '#!/path/to/interpreter' as the first line).

    This program is started once at startup of the Apache servers and then communicates with the rewriting engine over its stdin and stdout file-handles. For each map-function lookup it will receive the key to lookup as a newline-terminated string on stdin. It then has to give back the looked-up value as a newline-terminated string on stdout or the four-character string ``NULL'' if it fails (i.e., there is no corresponding value for the given key). A trivial program which will implement a 1:1 map (i.e., key == value) could be:

    #!/usr/bin/perl$| = 1;while (<STDIN>) {    # ...put here any transformations or lookups...    print $_;}

    But be very careful:

    1. ``Keep it simple, stupid'' (KISS), because if this program hangs it will hang the Apache server when the rule occurs.
    2. Avoid one common mistake: never do buffered I/O on stdout! This will cause a deadloop! Hence the ``$|=1'' in the above example...
    3. Use the RewriteLock directive to define a lockfile mod_rewrite can use to synchronize the communication to the program. By default no such synchronization takes place.
The RewriteMap directive can occur more than once. For each mapping-function use one RewriteMap directive to declare its rewriting mapfile. While you cannot declare a map in per-directory context it is of course possible to use this map in per-directory context.
Note: For plain text and DBM format files the looked-up keys are cached in-core until the mtime of the mapfile changes or the server does a restart. This way you can have map-functions in rules which are used for every request. This is no problem, because the external lookup only happens once!


Syntax: RewriteBase URL-path
Default: default is the physical directory path
Context: directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2

The RewriteBase directive explicitly sets the base URL for per-directory rewrites. As you will see below, RewriteRule can be used in per-directory config files (.htaccess). There it will act locally, i.e., the local directory prefix is stripped at this stage of processing and your rewriting rules act only on the remainder. At the end it is automatically added back to the path.

When a substitution occurs for a new URL, this module has to re-inject the URL into the server processing. To be able to do this it needs to know what the corresponding URL-prefix or URL-base is. By default this prefix is the corresponding filepath itself. But at most websites URLs are NOT directly related to physical filename paths, so this assumption will usually be wrong! There you have to use the RewriteBase directive to specify the correct URL-prefix.

Notice: If your webserver's URLs are not directly related to physical file paths, you have to use RewriteBase in every .htaccess files where you want to use RewriteRule directives.


Assume the following per-directory config file:
##  /abc/def/.htaccess -- per-dir config file for directory /abc/def#  Remember: /abc/def is the physical path of /xyz, i.e., the server#            has a 'Alias /xyz /abc/def' directive e.g.#RewriteEngine On#  let the server know that we were reached via /xyz and not#  via the physical path prefix /abc/defRewriteBase   /xyz#  now the rewriting rulesRewriteRule   ^oldstuff\.html$  newstuff.html

In the above example, a request to /xyz/oldstuff.html gets correctly rewritten to the physical file /abc/def/newstuff.html.

Note - For Apache hackers:
The following list gives detailed information about the internal processing steps:
Request:  /xyz/oldstuff.htmlInternal Processing:  /xyz/oldstuff.html     -> /abc/def/oldstuff.html  (per-server Alias)  /abc/def/oldstuff.html -> /abc/def/newstuff.html  (per-dir    RewriteRule)  /abc/def/newstuff.html -> /xyz/newstuff.html      (per-dir    RewriteBase)  /xyz/newstuff.html     -> /abc/def/newstuff.html  (per-server Alias)Result:  /abc/def/newstuff.html
This seems very complicated but is the correct Apache internal processing, because the per-directory rewriting comes too late in the process. So, when it occurs the (rewritten) request has to be re-injected into the Apache kernel! BUT: While this seems like a serious overhead, it really isn't, because this re-injection happens fully internally to the Apache server and the same procedure is used by many other operations inside Apache. So, you can be sure the design and implementation is correct.


Syntax: RewriteCond TestString CondPattern
Default: None
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

The RewriteCond directive defines a rule condition. Precede a RewriteRule directive with one or more RewriteCond directives. The following rewriting rule is only used if its pattern matches the current state of the URI and if these additional conditions apply too.

TestString is a string which can contains the following expanded constructs in addition to plain text:

  • RewriteRule backreferences: These are backreferences of the form
    (0 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the pattern from the corresponding RewriteRule directive (the one following the current bunch of RewriteCond directives).
  • RewriteCond backreferences: These are backreferences of the form
    (1 <= N <= 9) which provide access to the grouped parts (parentheses!) of the pattern from the last matched RewriteCond directive in the current bunch of conditions.
  • RewriteMap expansions: These are expansions of the form
    See the documentation for RewriteMap for more details.
  • Server-Variables: These are variables of the form
    where NAME_OF_VARIABLE can be a string taken from the following list:
    HTTP headers:


    connection & request:


    server internals:


    system stuff:




    Notice: These variables all correspond to the similarly named HTTP MIME-headers, C variables of the Apache server or struct tm fields of the Unix system. Most are documented elsewhere in the Manual or in the CGI specification. Those that are special to mod_rewrite include:

    Will contain the text "true" if the request currently being processed is a sub-request, "false" otherwise. Sub-requests may be generated by modules that need to resolve additional files or URIs in order to complete their tasks.
    This is the version of the Apache module API (the internal interface between server and module) in the current httpd build, as defined in include/ap_mmn.h. The module API version corresponds to the version of Apache in use (in the release version of Apache 1.3.14, for instance, it is 19990320:10), but is mainly of interest to module authors.
    The full HTTP request line sent by the browser to the server (e.g., "GET /index.html HTTP/1.1"). This does not include any additional headers sent by the browser.
    The resource requested in the HTTP request line. (In the example above, this would be "/index.html".)
    The full local filesystem path to the file or script matching the request.

Special Notes:

  1. The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same value, i.e., the value of the filename field of the internal request_rec structure of the Apache server. The first name is just the commonly known CGI variable name while the second is the consistent counterpart to REQUEST_URI (which contains the value of the uri field of request_rec).
  2. There is the special format: %{ENV:variable} where variable can be any environment variable. This is looked-up via internal Apache structures and (if not found there) via getenv() from the Apache server process.
  3. There is the special format: %{HTTP:header} where header can be any HTTP MIME-header name. This is looked-up from the HTTP request. Example: %{HTTP:Proxy-Connection} is the value of the HTTP header ``Proxy-Connection:''.
  4. There is the special format %{LA-U:variable} for look-aheads which perform an internal (URL-based) sub-request to determine the final value of variable. Use this when you want to use a variable for rewriting which is actually set later in an API phase and thus is not available at the current stage. For instance when you want to rewrite according to the REMOTE_USER variable from within the per-server context (httpd.conf file) you have to use %{LA-U:REMOTE_USER} because this variable is set by the authorization phases which come after the URL translation phase where mod_rewrite operates. On the other hand, because mod_rewrite implements its per-directory context (.htaccess file) via the Fixup phase of the API and because the authorization phases come before this phase, you just can use %{REMOTE_USER} there.
  5. There is the special format: %{LA-F:variable} which performs an internal (filename-based) sub-request to determine the final value of variable. Most of the time this is the same as LA-U above.

CondPattern is the condition pattern, i.e., a regular expression which is applied to the current instance of the TestString, i.e., TestString is evaluated and then matched against CondPattern.

Remember: CondPattern is a standard Extended Regular Expression with some additions:

  1. You can prefix the pattern string with a '!' character (exclamation mark) to specify a non-matching pattern.
  2. There are some special variants of CondPatterns. Instead of real regular expression strings you can also use one of the following:
    • '<CondPattern' (is lexically lower)
      Treats the CondPattern as a plain string and compares it lexically to TestString. True if TestString is lexically lower than CondPattern.
    • '>CondPattern' (is lexically greater)
      Treats the CondPattern as a plain string and compares it lexically to TestString. True if TestString is lexically greater than CondPattern.
    • '=CondPattern' (is lexically equal)
      Treats the CondPattern as a plain string and compares it lexically to TestString. True if TestString is lexically equal to CondPattern, i.e the two strings are exactly equal (character by character). If CondPattern is just "" (two quotation marks) this compares TestString to the empty string.
    • '-d' (is directory)
      Treats the TestString as a pathname and tests if it exists and is a directory.
    • '-f' (is regular file)
      Treats the TestString as a pathname and tests if it exists and is a regular file.
    • '-s' (is regular file with size)
      Treats the TestString as a pathname and tests if it exists and is a regular file with size greater than zero.
    • '-l' (is symbolic link)
      Treats the TestString as a pathname and tests if it exists and is a symbolic link.
    • '-F' (is existing file via subrequest)
      Checks if TestString is a valid file and accessible via all the server's currently-configured access controls for that path. This uses an internal subrequest to determine the check, so use it with care because it decreases your servers performance!
    • '-U' (is existing URL via subrequest)
      Checks if TestString is a valid URL and accessible via all the server's currently-configured access controls for that path. This uses an internal subrequest to determine the check, so use it with care because it decreases your server's performance!
    Notice: All of these tests can also be prefixed by an exclamation mark ('!') to negate their meaning.

Additionally you can set special flags for CondPattern by appending

as the third argument to the RewriteCond directive. Flags is a comma-separated list of the following flags:
  • 'nocase|NC' (no case)
    This makes the test case-insensitive, i.e., there is no difference between 'A-Z' and 'a-z' both in the expanded TestString and the CondPattern. This flag is effective only for comparisons between TestString and CondPattern. It has no effect on filesystem and subrequest checks.
  • 'ornext|OR' (or next condition)
    Use this to combine rule conditions with a local OR instead of the implicit AND. Typical example:
    RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]RewriteCond %{REMOTE_HOST}  ^host3.*RewriteRule ...some special stuff for any of these hosts...
    Without this flag you would have to write the cond/rule three times.


To rewrite the Homepage of a site according to the ``User-Agent:'' header of the request, you can use the following:
RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*RewriteRule  ^/$                 /homepage.max.html  [L]RewriteCond  %{HTTP_USER_AGENT}  ^Lynx.*RewriteRule  ^/$                 /homepage.min.html  [L]RewriteRule  ^/$                 /homepage.std.html  [L]
Interpretation: If you use Netscape Navigator as your browser (which identifies itself as 'Mozilla'), then you get the max homepage, which includes Frames, etc. If you use the Lynx browser (which is Terminal-based), then you get the min homepage, which contains no images, no tables, etc. If you use any other browser you get the standard homepage.


Syntax: RewriteRule Pattern Substitution
Default: None
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Extension
Module: mod_rewrite.c
Compatibility: Apache 1.2 (partially), Apache 1.3

The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once. Each directive then defines one single rewriting rule. The definition order of these rules is important, because this order is used when applying the rules at run-time.

Pattern can be (for Apache 1.1.x a System V8 and for Apache 1.2.x and later a POSIX) regular expression which gets applied to the current URL. Here ``current'' means the value of the URL when this rule gets applied. This may not be the originally requested URL, because any number of rules may already have matched and made alterations to it.

Some hints about the syntax of regular expressions:

Text:  .           Any single character  [chars]     Character class: One  of chars  [^chars]    Character class: None of chars  text1|text2 Alternative: text1 or text2Quantifiers:  ?           0 or 1 of the preceding text  *           0 or N of the preceding text (N > 0)  +           1 or N of the preceding text (N > 1)Grouping:  (text)      Grouping of text              (either to set the borders of an alternative or              for making backreferences where the Nth group can               be used on the RHS of a RewriteRule with $N)Anchors:  ^           Start of line anchor  $           End   of line anchorEscaping:  \char       escape that particular char              (for instance to specify the chars ".[]()" etc.)

For more information about regular expressions either have a look at your local regex(3) manpage or its src/regex/regex.3 copy in the Apache 1.3 distribution. If you are interested in more detailed information about regular expressions and their variants (POSIX regex, Perl regex, etc.) have a look at the following dedicated book on this topic:

Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O'Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

Additionally in mod_rewrite the NOT character ('!') is a possible pattern prefix. This gives you the ability to negate a pattern; to say, for instance: ``if the current URL does NOT match this pattern''. This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule.

Notice: When using the NOT character to negate a pattern you cannot have grouped wildcard parts in the pattern. This is impossible because when the pattern does NOT match, there are no contents for the groups. In consequence, if negated patterns are used, you cannot use $N in the substitution string!

Substitution of a rewriting rule is the string which is substituted for (or replaces) the original URL for which Pattern matched. Beside plain text you can use

  1. back-references $N to the RewriteRule pattern
  2. back-references %N to the last matched RewriteCond pattern
  3. server-variables as in rule condition test-strings (%{VARNAME})
  4. mapping-function calls (${mapname:key|default})
Back-references are $N (N=0..9) identifiers which will be replaced by the contents of the Nth group of the matched Pattern. The server-variables are the same as for the TestString of a RewriteCond directive. The mapping-functions come from the RewriteMap directive and are explained there. These three types of variables are expanded in the order of the above list.

As already mentioned above, all the rewriting rules are applied to the Substitution (in the order of definition in the config file). The URL is completely replaced by the Substitution and the rewriting process goes on until there are no more rules unless explicitly terminated by a L flag - see below.

There is a special substitution string named '-' which means: NO substitution! Sounds silly? No, it is useful to provide rewriting rules which only match some URLs but do no substitution, e.g., in conjunction with the C (chain) flag to be able to have more than one pattern to be applied before a substitution occurs.

One more note: You can even create URLs in the substitution string containing a query string part. Just use a question mark inside the substitution string to indicate that the following stuff should be re-injected into the QUERY_STRING. When you want to erase an existing query string, end the substitution string with just the question mark.

Note: There is a special feature: When you prefix a substitution field with http://thishost[:thisport] then mod_rewrite automatically strips it out. This auto-reduction on implicit external redirect URLs is a useful and important feature when used in combination with a mapping-function which generates the hostname part. Have a look at the first example in the example section below to understand this.
Remember: An unconditional external redirect to your own server will not work with the prefix http://thishost because of this feature. To achieve such a self-redirect, you have to use the R-flag (see below).

Additionally you can set special flags for Substitution by appending

as the third argument to the RewriteRule directive. Flags is a comma-separated list of the following flags:
  • 'redirect|R [=code]' (force redirect)
    Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no code is given a HTTP response of 302 (MOVED TEMPORARILY) is used. If you want to use other response codes in the range 300-400 just specify them as a number or use one of the following symbolic names: temp (default), permanent, seeother. Use it for rules which should canonicalize the URL and give it back to the client, e.g., translate ``/~'' into ``/u/'' or always append a slash to /u/user, etc.

    Note: When you use this flag, make sure that the substitution field is a valid URL! If not, you are redirecting to an invalid location! And remember that this flag itself only prefixes the URL with http://thishost[:thisport]/, rewriting continues. Usually you also want to stop and do the redirection immediately. To stop the rewriting you also have to provide the 'L' flag.

  • 'forbidden|F' (force URL to be forbidden)
    This forces the current URL to be forbidden, i.e., it immediately sends back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs.
  • 'gone|G' (force URL to be gone)
    This forces the current URL to be gone, i.e., it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark pages which no longer exist as gone.
  • 'proxy|P' (force proxy)
    This flag forces the substitution part to be internally forced as a proxy request and immediately (i.e., rewriting rule processing stops here) put through the proxy module. You have to make sure that the substitution string is a valid URI (e.g., typically starting with http://hostname) which can be handled by the Apache proxy module. If not you get an error from the proxy module. Use this flag to achieve a more powerful implementation of the ProxyPass directive, to map some remote stuff into the namespace of the local server.

    Notice: To use this functionality make sure you have the proxy module compiled into your Apache server program. If you don't know please check whether mod_proxy.c is part of the ``httpd -l'' output. If yes, this functionality is available to mod_rewrite. If not, then you first have to rebuild the ``httpd'' program with mod_proxy enabled.

  • 'last|L' (last rule)
    Stop the rewriting process here and don't apply any more rewriting rules. This corresponds to the Perl last command or the break command from the C language. Use this flag to prevent the currently rewritten URL from being rewritten further by following rules. For example, use it to rewrite the root-path URL ('/') to a real one, e.g., '/e/www/'.
  • 'next|N' (next round)
    Re-run the rewriting process (starting again with the first rewriting rule). Here the URL to match is again not the original URL but the URL from the last rewriting rule. This corresponds to the Perl next command or the continue command from the C language. Use this flag to restart the rewriting process, i.e., to immediately go to the top of the loop.
    But be careful not to create an infinite loop!
  • 'chain|C' (chained with next rule)
    This flag chains the current rule with the next rule (which itself can be chained with the following rule, etc.). This has the following effect: if a rule matches, then processing continues as usual, i.e., the flag has no effect. If the rule does not match, then all following chained rules are skipped. For instance, use it to remove the ``.www'' part inside a per-directory rule set when you let an external redirect happen (where the ``.www'' part should not to occur!).
  • 'type|T=MIME-type' (force MIME type)
    Force the MIME-type of the target file to be MIME-type. For instance, this can be used to simulate the mod_alias directive ScriptAlias which internally forces all files inside the mapped directory to have a MIME type of ``application/x-httpd-cgi''.
  • 'nosubreq|NS' (used only if no internal sub-request)
    This flag forces the rewriting engine to skip a rewriting rule if the current request is an internal sub-request. For instance, sub-requests occur internally in Apache when mod_include tries to find out information about possible directory default files ( On sub-requests it is not always useful and even sometimes causes a failure to if the complete set of rules are applied. Use this flag to exclude some rules.

    Use the following rule for your decision: whenever you prefix some URLs with CGI-scripts to force them to be processed by the CGI-script, the chance is high that you will run into problems (or even overhead) on sub-requests. In these cases, use this flag.

  • 'nocase|NC' (no case)
    This makes the Pattern case-insensitive, i.e., there is no difference between 'A-Z' and 'a-z' when Pattern is matched against the current URL.
  • 'qsappend|QSA' (query string append)
    This flag forces the rewriting engine to append a query string part in the substitution string to the existing one instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule.
  • 'noescape|NE' (no URI escaping of output)
    This flag keeps mod_rewrite from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as '%', '$', ';', and so on) will be escaped into their hexcode equivalents ('%25', '%24', and '%3B', respectively); this flag prevents this from being done. This allows percent symbols to appear in the output, as in
        RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE]   
    which would turn '/foo/zed' into a safe request for '/bar?arg=P1=zed'.
    Notice: The noescape flag is only available with Apache 1.3.20 and later versions.
  • 'passthrough|PT' (pass through to next handler)
    This flag forces the rewriting engine to set the uri field of the internal request_rec structure to the value of the filename field. This flag is just a hack to be able to post-process the output of RewriteRule directives by Alias, ScriptAlias, Redirect, etc. directives from other URI-to-filename translators. A trivial example to show the semantics: If you want to rewrite /abc to /def via the rewriting engine of mod_rewrite and then /def to /ghi with mod_alias:
        RewriteRule ^/abc(.*)  /def$1 [PT]    Alias       /def       /ghi   
    If you omit the PT flag then mod_rewrite will do its job fine, i.e., it rewrites uri=/abc/... to filename=/def/... as a full API-compliant URI-to-filename translator should do. Then mod_alias comes and tries to do a URI-to-filename transition which will not work.

    Note: You have to use this flag if you want to intermix directives of different modules which contain URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite..

  • 'skip|S=num' (skip next rule(s))
    This flag forces the rewriting engine to skip the next num rules in sequence when the current rule matches. Use this to make pseudo if-then-else constructs: The last rule of the then-clause becomes skip=N where N is the number of rules in the else-clause. (This is not the same as the 'chain|C' flag!)
  • 'env|E=VAR:VAL' (set environment variable)
    This forces an environment variable named VAR to be set to the value VAL, where VAL can contain regexp backreferences $N and %N which will be expanded. You can use this flag more than once to set more than one variable. The variables can be later dereferenced in many situations, but usually from within XSSI (via <!--#echo var="VAR"-->) or CGI (e.g. $ENV{'VAR'}). Additionally you can dereference it in a following RewriteCond pattern via %{ENV:VAR}. Use this to strip but remember information from URLs.
Note: Never forget that Pattern is applied to a complete URL in per-server configuration files. But in per-directory configuration files, the per-directory prefix (which always is the same for a specific directory!) is automatically removed for the pattern matching and automatically added after the substitution has been done. This feature is essential for many sorts of rewriting, because without this prefix stripping you have to match the parent directory which is not always possible.

There is one exception: If a substitution string starts with ``http://'' then the directory prefix will not be added and an external redirect or proxy throughput (if flag P is used!) is forced!

Note: To enable the rewriting engine for per-directory configuration files you need to set ``RewriteEngine On'' in these files and ``Options FollowSymLinks'' must be enabled. If your administrator has disabled override of FollowSymLinks for a user's directory, then you cannot use the rewriting engine. This restriction is needed for security reasons.

Here are all possible substitution combinations and their meanings:

Inside per-server configuration (httpd.conf)
for request ``GET /somepath/pathinfo'':

Given Rule                                      Resulting Substitution----------------------------------------------  ----------------------------------^/somepath(.*) otherpath$1                      not supported, because invalid!^/somepath(.*) otherpath$1  [R]                 not supported, because invalid!^/somepath(.*) otherpath$1  [P]                 not supported, because invalid!----------------------------------------------  ----------------------------------^/somepath(.*) /otherpath$1                     /otherpath/pathinfo^/somepath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo                                                via external redirection^/somepath(.*) /otherpath$1 [P]                 not supported, because silly!----------------------------------------------  ----------------------------------^/somepath(.*) http://thishost/otherpath$1      /otherpath/pathinfo^/somepath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo                                                via external redirection^/somepath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!----------------------------------------------  ----------------------------------^/somepath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo                                                via external redirection^/somepath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo                                                via external redirection                                                (the [R] flag is redundant)^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo                                                via internal proxy

Inside per-directory configuration for /somepath
(i.e., file .htaccess in dir /physical/path/to/somepath containing RewriteBase /somepath)
for request ``GET /somepath/localpath/pathinfo'':

Given Rule                                      Resulting Substitution----------------------------------------------  ----------------------------------^localpath(.*) otherpath$1                      /somepath/otherpath/pathinfo^localpath(.*) otherpath$1  [R]                 http://thishost/somepath/otherpath/pathinfo                                                via external redirection^localpath(.*) otherpath$1  [P]                 not supported, because silly!----------------------------------------------  ----------------------------------^localpath(.*) /otherpath$1                     /otherpath/pathinfo^localpath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo                                                via external redirection^localpath(.*) /otherpath$1 [P]                 not supported, because silly!----------------------------------------------  ----------------------------------^localpath(.*) http://thishost/otherpath$1      /otherpath/pathinfo^localpath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo                                                via external redirection^localpath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!----------------------------------------------  ----------------------------------^localpath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo                                                via external redirection^localpath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo                                                via external redirection                                                (the [R] flag is redundant)^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo                                                via internal proxy


We want to rewrite URLs of the form
/ Language /~ Realname /.../ File
/u/ Username /.../ File . Language

We take the rewrite mapfile from above and save it under /path/to/file/map.txt. Then we only have to add the following lines to the Apache server configuration file:

RewriteLog   /path/to/file/rewrite.logRewriteMap   real-to-user               txt:/path/to/file/map.txtRewriteRule  ^/([^/]+)/~([^/]+)/(.*)$   /u/${real-to-user:$2|nobody}/$3.$1


Environment Variables

This module keeps track of two additional (non-standard) CGI/SSI environment variables named SCRIPT_URL and SCRIPT_URI. These contain the logical Web-view to the current resource, while the standard CGI/SSI variables SCRIPT_NAME and SCRIPT_FILENAME contain the physical System-view.

Notice: These variables hold the URI/URL as they were initially requested, i.e., before any rewriting. This is important because the rewriting process is primarily used to rewrite logical URLs to physical pathnames.



Practical Solutions

We also have an URL Rewriting Guide available, which provides a collection of practical solutions for URL-based problems. There you can find real-life rulesets and additional information about mod_rewrite.

Apache HTTP Server Version 1.3

Index Home

2006/09/11 10:19 2006/09/11 10:19
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 여러가지를 꿈꾸는 풀잎이

트래픽 모니터링을 위한 아파치 모듈 : mod-cband

아파치 2.0.5버전(2006년 기준), 즉 아파치가 버전 업이 되면서 호스팅(서버를 일정 부분 유저에게 할당을 해서 웹 서비스를 제공해주는 서비스)서비스 중 가장 중요한 트래픽 모니터링에 대한 모듈의 부재가 나타났다. 아파치 1.3이상 버전에서만 지원되는 mod-throttle이라는 트래픽 제어 모듈을사용하기 위해 많은 서버 관리자들은 아파치를 다운그레이하여 사용할 수 밖에 없었는데 mod-cband는 이러한 상황을 해결해주는데 충분한 기능을 가졌다. 물론 필자는 mod-throttle을 사용해보지 않았기 때문에 그 기능상의 차이점을 적지 못하는 점을 양해해 주기 바란다. (리눅스 서버관리를 파고 들은지가 이제 겨우 3개월 되었습니다. 그렇기 때문에 아직 많이 미숙하기 때문에 이것저것 질문 하셔도 답변을 해드릴 수 없을지도 모릅니다. 그리고 이 문서는 제가 연구하면서 작성하는 것이기 때문에 일부로 존칭을 생략하였습니다. 양해해주시기 바라며 아파치 이제 다운그레이 하지 말고 사용 해보도록 합시다!!!)

- mod-cband

트래픽 양을 제한하고 모니터링 할 수 있는 모듈로 설치가 쉽고 적용이 매우 쉬우며 사용방법도 매우 간단하다. 현재 mod-cband 모듈을 완벽히 제어를 하는 법을 모르기 때문에 큰 내용을 여기서 작성하지는 않는다.

- 설치 하기

링크 :

우선 위 링크를 통해 해당 웹페이지로 이동을 하여 mod-cband_0.9.7.1.orig.tar.gz 파일을 받는다. 그런 뒤에 적당한 곳에 압축을 푼다. 안에 매뉴얼을 보면 설치하는 방식은 딱 6줄이다.

$ wget

$ tar xzvf mod-cband-

$ cd mod-cband-

$ ./configure

$ make

$ make install

이렇게 하면 설치가 된다. 하지만 그전에 모드가 dso so방식. 동적 모듈 로딩으로 초기 설치시 셋팅이 되어 있어야 한다. 필자는 그 전에 셋팅을 위와 같이 했으므로 그 부분은 넘어가도록 한다. 동정 모듈 로딩은 앞으로 중요 프로그램 설치시에 크게 필요하므로 셋팅이 안되어있다면 추가 컴파일을 통해 셋팅을 다시 하도록 하자.

필자는 위와 같이 했을 때 설치를 하지 못했다. 설치가 안되는 사람의 경우에는 다음과 같이 해야 한다. 이건 나름대로 필자가 성공한 방법이기 때문에 모든 사용자의 컴퓨터 리눅스 환경에서 완벽히 성공한다는 보장은 없지만 아마 될 것이다.

$./configure –with-apxs=/아파치2가 깔려있는 PATH/bin/apxs

configure 설정 시 다음처럼만 하면 기분좋은 화면을 볼 수 있을 것이다. 위 구문을 살짝 이야기 하자면 모듈 추가를 위한 apxs의 직접적인 패스를 달아준 것이다. 필자는 이제 리눅스 입문하는 단계 이기 때문에 남들처럼 잘하지 못한다. 일일이 왜 그랫나 설명은 삼가하겠다. 그럼 이제 자동으로 모듈추가도 해주기 때문에 의기양양하게 phpinfo() 함수를 이용해 loaded module란을 확인해보자. cband가 추가되어있는 것을 확인 할 수 있을 것이다. 이제 아파치 설정을 해야 한다.

아파치 설정은 압축 파일 안에 있는 샘플을 보면서 서버 환경에 맞게 설정을 하면 된다. 간단히 몇가지를 이야기 하자면 필자는 샘플 2의 방식을 사용했다. 클래스 방식을 사용하는건 너무 어려웠다.(귀찮기도 했다.)

# define user 'dembol'

<CBandUser dembol>

   # 200MB bandwidth limit for user 'dembol'

   CBandUserLimit 200000

   # redirect to

   # when the limit has been reached


   # user's scoreboard file

   CBandUserScoreboard /var/run/apache2/dembol.scoreboard


   # a period of time after which the scoreboard will be cleared (2 minutes) (only in >=0.9.5-rc2)

   CBandUserPeriod 2M


우선 먼저 유저를 등록한다. 이건 샘플문서에 나와있는 내용으로 하나 하나 설명을 해보겠다. 유저의 이름은 dembol이고 200MB로 한정했다. ExceedeURL의 경우는 트래픽 오버가 나면 이동한 페이지이다. 이부분에서 아직 테스트가 완벽히 이루어지지 않아 자세히는 모르겠지만 현재 상황을 보면 순식간에 루프를 돌아버렸다. 생각해보니 트래픽 제한한 계정으로의 이동을 다시 또 이동을 시켰으니 루프를 돌 수 밖에 없었던 게 아닌가 생각한다. scoreboard는 아직 잘 모르겠지만. 우선은 시키는 대로 했다. 그 다음은 scoreboard가 클리어 되는 시간을 설정한다. 여기서 사용하는 것을 보면 (M : , H : 시간, 없으면 초) 대충 이런 식으로 설정을 하는 것으로 보인다.

# assign virtualhost '' to user 'dembol'

<VirtualHost *:80>


   # Specify virtualhost owner

  CBandUser dembol


   # 100MB virtualhost bandwidth limit

   CBandLimit 100000

   # redirect to

   # when the limit has been reached


   # virtualhost's scoreboard file

   CBandScoreboard /var/run/apache2/


   # a period of time after which the scoreboard will be cleared (3 hours) (only in >=0.9.5-rc2)

   CBandPeriod 3H


이것은 위에서 설정한 유저를 바탕으로 직접적인 호스팅의 제어를 하는 곳이다. 이렇게 하기 싫고 특수 유저에 맞게 할당을 하고자 한다면 이 샘플 바로 위에 있는 가상호스트의 제어만 하는 것을 하도록 한다. 위에서 말했듯이 가상호스트 설정은 비슷하니 설명은 빼도록 하겠다.

이제 위 방식의 효율성을 잠시 써보도록 하겠습니다. 웹호스팅 서비스를 할 때 이런 글을 본적이 있을 것이다. 트래픽 제한은 하지 않겠지만 만약 전체 점유율이 다음과 같으면 잠시 트래픽을 제한한다. 라는 글을 본 적 있을 것이다. 이런 것처럼 유저의 트래픽은 가상호스트의 계정과 따로 트래픽을 관리하게 된다. 그렇기 때문에 가상호스트 계정의 트래픽 오버가 나도 유저의 트래픽은 걸리지 않는 것이다. 이것을 이용하면 전체 계정의 트래픽양을 제어 할 수 있을 것이다.

문제는 아직 모듈 분석을 다 하지 못해서 자동으로 서버 가동 24시간이면 클리어 되게 하는 법을 모르고 있다. 혹시라도 알게 되면 다시 글에 덧붙이도록 하겠다.

이제 모니터링을 할 수 있는 부분을 추가해야 하는데, 제작자는 httpd.conf파일에 다음과 같은 구문을 몇 줄 추가해야만 볼 수 있게 해놓았으니 다음 라인을 추가한다.

<Location /cband-status>

SetHandler cband-status


필자는 httpd.conf맨 마지막 페이지에 삽입을 하였으나 여러분들은 각자 알아서 원하는 위치에 넣도록 하자. 이제 위 작업이 모두 끝나고 각 가상 호스트에게로의 트래픽 사용량 제한을 완료 하였다면 아파치를 재 실행하여 다음 주소로 접근을 해보자.


이렇게 되면 한 곳에서 모니터링이 가능 할 것이다.

2006/09/11 10:08 2006/09/11 10:08
이 글에는 트랙백을 보낼 수 없습니다
«이전  1 ... 2 3 4 5 6 7 8 9 10 ... 11  다음»
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2024/06   »
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)