首先用“記事本”程序打開“httpd.conf”配置文件。此文件存放在apache服務器安裝路徑下的“conf”文件夾內。
一、使用 mod_vhost_alias
１.簡單的動態虛擬主機
（1）從 Host: 頭中取得服務器名字 Server Name
UseCanonicalName Off
（2）這裡的日志格式，可以在將來通過第一個參數域來分隔不同的虛擬主機的日志
LogFormat "%V %h %l %u %t \"%r\" %s %b" VCommon
CustomLog logs/Access_log vcommon
（3）在返回請求的文件名的路徑中包含進服務器名字: server name
VirtualDocumentRoot /www/hosts/%0/docs
VirtualScriptAlias /www/hosts/%0/CGI-bin
2.更為有效的基於 IP 地址的虛擬主機
（1）從 IP 地址反解析得到服務器名字（server name）
UseCanonicalName DNS
（2）在日志中包含 IP 地址，便於後續分發
LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/Access_log vcommon
（3）在文件路徑中包含 IP 地址
VirtualDocumentRootIP /www/hosts/%0/docs
VirtualScriptAliasIP /www/hosts/%0/CGI-bin
二、使用 mod_rewrite
1. 使用 mod_rewrite 實現簡單的動態虛擬主機
（１）從 Host: 頭獲取服務器名字
UseCanonicalName Off
（２）可分割的日志
LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/Access_log vcommon
<Directory /www/hosts>
ExecCGI is needed here because we can't force
CGI execution in the way that ScriptAlias does
Options FollowSymLinks ExecCGI
</Directory>
（３）接下來是關鍵部分
RewriteEngine On
a ServerName derived from a Host: header may be any case at all RewriteMap lowercase int:tolower
首先處理普通文檔:
允許變名 /icons/ 起作用 - 其他變名類同
RewriteCond %{REQUEST_URI} !^/icons/
允許 CGIS
RewriteCond %{REQUEST_URI} !^/CGI-bin/
開始“變戲法”
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1
現在處理 CGIs - 我們需要強制使用一個 MIME 類型
RewriteCond %{REQUEST_URI} ^/CGI-bin/
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd- CGI]
2.使用獨立的虛擬主機配置文件 vhost.map
（１）vhost.map 文件包含了類似下面的內容:
www.customer-1.com /www/customers/1
www.customer-2.com /www/customers/2
...
www.customer-N.com /www/customers/N
（２）http.conf 包含了:
RewriteEngine on
RewriteMap lowercase int:tolower
（３）定義映像文件
RewriteMap vhost txt:/www/conf/vhost.map
（４）和上面的例子一樣，處理變名
RewriteCond %{REQUEST_URI} !^/icons/
RewriteCond %{REQUEST_URI} !^/CGI-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
（５）這裡做基於文件的重新映射
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/docs/$1
RewriteCond %{REQUEST_URI} ^/CGI-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/CGI-bin/$1
.htAccess文件功能
.htAccess文件的功能:"分布式配置文件"提供了針對目錄改變配置的方法,即:在一個特定的文檔目錄中放置一個包含一個或多個指令的文件， 以作用於此目錄及其所有子目錄。作為用戶，所能使用的命令受到限制。管理員可以通過apache 的AllowOverride指令來設置.子目錄中的指令會覆蓋更高級目錄或者主服務器配置文件中的指令。
一、錯誤文檔的定位
（１）常用的客戶端請求錯誤返回代碼：
401 Authorization Required
403 Forbidden
404 Not Found
405 Method Not Allowed
408 Request Timed Out
411 Content Length Required
412 Precondition Failed
413 Request Entity Too Long
414 Request URI Too Long
415 Unsupported Media Type
（２）常見的服務器錯誤返回代碼：
500 Internal Server Error
（３）用戶可以利用.htaccess指定自己事先制作好的錯誤提醒頁面。一般情況下，人們可以專門設立一個目錄，例如errors放置這些頁面。然後再.htAccess中，加入如下的指令：
ErrorDocument 404 /errors/notfound.Html
ErrorDocument 500 /errors/internalerror.Html
一條指令一行。
上述第一條指令的意思是對於404，也就是沒有找到所需要的文檔的時候得顯示頁面為/errors目錄下的notfound.Html頁面。不難看出語法格式為：
ErrorDocument 錯誤代碼 /目錄名/文件名.擴展名
如果所需要提示的信息很少的話，不必專門制作頁面，直接在指令中使用Html號了，例如下面這個例子：
ErrorDocument 401 "<body bgcolor=#ffffff>
你沒有權限訪問該頁面！
</body>"
二、文檔訪問的密碼保護要利用.htAccess對某個目錄下的文檔設定訪問用戶和對應的密碼，首先要做的是生成一個.htpasswd的文本文檔，例如：
zheng:y4E7Ep8e7EYV
這裡密碼經過加密，用戶可以自己找些工具將密碼加密成.htAccess支持的編碼。該文檔最好不要放在www目錄下，建議放在www根目錄文檔之外，這樣更為安全些。
有了授權用戶文檔，可以在.htAccess中加入如下指令了：
AuthUserFile .htpasswd的服務器目錄
AuthGroupFile /dev/null （需要授權訪問的目錄）
AuthName EntERPassWord
AuthType Basic （授權類型）
require user wsabstract （允許訪問的用戶，如果希望表中所有用戶都允許，可以使用 require valid-user）
注:括號部分為學習時候自己添加的注釋
三、拒絕來自某個IP的訪問
如果我不想某個政府部門訪問到我的站點的內容，那可以通過.htAccess中加入該部門的IP而將它們拒絕在外。 例如：
order allow,deny
deny from 210.21.112.43
deny from 219.146.95
allow from all
注: 第二行拒絕某個IP，第三行拒絕某個IP段，也就是219.146.95.0~219.146.95.255 想要拒絕所有人？用deny from all好了。不止用IP，也可以用域名來設定。
四、保護.htAccess文檔
在使用.htaccess來設置目錄的密碼保護時，它包含了密碼文件的路徑。從安全考慮，有必要把.htaccess也保護起來，不讓別人看到其中的內容。雖然可以用其他方式做到這點，比如文檔的權限。不過，.htAccess本身也能做到，只需加入如下的指令：
<Files .htAccess>
order allow,deny
deny from all
</Files>
五、URL轉向
我們可能對網站進行重新規劃，將文檔進行了遷移，或者更改了目錄。這時候，來自搜索引擎或者其他網站鏈接過來的訪問就可能出錯。這種情況下，可以通過如下指令來完成舊的URL自動轉向到新的地址：
Redirect /舊目錄/舊文檔名 新文檔的地址
或者整個目錄的轉向：
Redirect 舊目錄 新目錄
改變缺省的首頁文件
一般情況下缺省的首頁文件名有default、index等。不過，有些時候目錄中沒有缺省文件，而是某個特定的文件名，比如在pmwiki中是pmwiki.PHP。這種情況下，要用戶記住文件名來訪問很麻煩。在.htAccess中可以輕易的設置新的缺省文件名：
DirectoryIndex 新的缺省文件名
也可以列出多個，順序表明它們之間的優先級別，
例如：
DirectoryIndex filename.Html index.CGI index.pl default.htm
rewrite重寫功能
apache模塊 mod_rewrite，一個基於一定規則的實時重寫URL請求的引擎此模塊提供了一個基於正則表達式分析器的重寫引擎來實時重寫URL請求。它支持每個完整規則可以擁有不限數量的子規則以及附加條件規則的靈活而且強大的URL操作機制。此URL操作可以依賴於各種測試，比如服務器變量、環境變量、HTTP頭、時間標記，甚至各種格式的用於匹配URL組成部分的查找數據庫。此模塊可以操作URL的所有部分(包括路徑信息部分)，在服務器級的(httpd.conf)和目錄級的(.htAccess)配置都有效，還可以生成最終請求字符串。此重寫操作的結果可以是內部子處理，也可以是外部請求的轉向，甚至還可以是內部代理處理。但是，所有這些功能和靈活性帶來一個問題，那就是復雜性，因此，不要指望一天之內就能看懂整個模塊。更多的討論、細節、示例，請查看詳細的URL重寫文檔。
（１）特殊字符的引用:
在apache 1.3.20中，TestString和Substitution中的特殊字符可以用前導斜槓(\)來實現轉義(即忽略其特殊含義而視
之為普通字符)。 比如，Substitution可以用"\___FCKpd___27quot;來包含一個美元符號，以避免mod_rewrite把它視為反向引用。
（２）環境變量
此模塊會跟蹤兩個額外的(非標准)CGI/SSI環境變量，SCRIPT_URL和SCRIPT_URI。他們包含了當前資源的邏輯網絡視圖，而標准CGI/SSI變量SCRIPT_NAME和SCRIPT_FILENAME包含的是物理系統視圖。注意：這些變量保持的是其最初被請求時的URI/URL，即在任何重寫操作之前的URI/URL。其重要性在於他們是重寫操作重寫URL到物理路徑名的原始依據。
示例:
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.Html
SCRIPT_FILENAME=/u/rse/.www/index.Html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/
（３）rewrite的指令
rewrite的指令有很多比如RewriteBase 指令
RewriteBase指令顯式地設置了目錄級重寫的基准URL。在下文中，你將看到RewriteRule可以用於目錄級的配置文件中(.htAccess)並在局部范圍內起作用，即規則實際處理的只是剝離了本地路徑前綴的一部分。處理結束後，這個路徑會被自動地附著回去。默認值是"RewriteBase physical-directory-path"。
在對一個新的URL進行替換時，此模塊必須把這個URL重新注入到服務器處理中。為此，它必須知道其對應的URL前綴或者說URL基准。通常，此前綴就是對應的文件路徑。但是，大多數網站URL不是直接對應於其物理文件路徑的，因而一般不能做這樣的假定! 所以在這種情況下，就必須用RewriteBase指令來指定正確的URL前綴。
如果你的網站服務器URL不是與物理文件路徑直接對應的，而又需要使用RewriteBase指令，則必須在每個對應的.htAccess文件中指定RewriteRule 。
例如，目錄級配置文件內容如下：
/abc/def/.htAccess -- /abc/def 目錄的配置文件
注意：/abc/def 是 /xyz 的物理路徑(例如存在一條'Alias /xyz /abc/def'指令)。
RewriteEngine On
讓服務器知道我們使用的是 /xyz 而不是物理路徑 /abc/def
RewriteBase /xyz
重寫規則
RewriteRule ^oldstuff\.html$ newstuff.Html
注:上述例子中，對/xyz/oldstuff.html的請求被正確地重寫為對物理文件/abc/def/newstuff.Html的請求。
以下列出了內部處理的詳細步驟：
請求:
/xyz/oldstuff.Html
內部處理過程:
/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)
結果:
/abc/def/newstuff.Html
雖然這個過程看來很繁復，但是由於目錄級重寫的到來時機已經太晚了，它不得不把這個(重寫)請求重新注入到Apache核心中，所以Apache內部確實是這樣處理的。但是：它的開銷並不象看起來的那樣大，因為重新注入完全在apache服務器內部進行，而且這樣的過程在apache內部也為其他許多操作所使用。所以，你可以充分信任其設計和實現是正確的。
