Apacheserver自己定义404错误页面有两种方法：
第一种方法最简单，直接在Apache的httpd.conf下进行配置改动命令，改动的内容请參看.htaccess命令写法中的自己定义错误页面
另外一种方法能够在.htaccess文件里配置命令，详细操作请參看.htaccess命令写法中的自己定义错误页面
.htaccess用法总结
1 . 首先让的本地APACHEserver器同意.htaccess改动
打开httpd.conf
(1)
Options FollowSymLinks
AllowOverride None
改为
Options FollowSymLinks
AllowOverride All
(2)去掉以下的凝视
LoadModule rewrite_module modules/mod_rewrite.so
2. htaccess 写法
●创建一个.htaccess文档
.htaccess没有文件名称，仅仅有一个由8个字母组成的扩展名，只是实际上它是linux下的命名，在Win系统中是不能够直接通过“新建”文件来创建的
只是我们有两种方法来创建
第一种：利用cmd中的copy来实现，比方copy sample.txt .htaccess
另外一种：先创建一个htaccess.txt，然后Ftp到server，通过FTP来改动文件名称。
●保护.htaccess文档
在.htaccess来设置文件夹的password保护时，它包括了password的路径。从安全考虑，有必要把.htaccess也保护起来，不让别人看到当中的。尽管用其它做到这点，好比文档的权限。不外，.htaccess本身也能做到，仅仅需增加例如以下的指令：
order allow,deny
deny from all
●自己定义错误页
.htaccess的一个应用是自己定义错误页面，这将使你能够拥有自己的、个性化的错误页面（比如找不到文件时），而不是你的服务商提供的错误页或没有不论什么页面。这会让你的站点在出错的时候看上去更专业。你还能够利用脚本程序在错误发生的时候通知你（比如当找不到页面的时候自己主动Email给你）。
你所知道的不论什么页面错误代码（像404找不到页面），都能够通过在.htaccess文件中增加以下的文字将其变成自己定义页面：
ErrorDocument errornumber /file.html
举例来说，假设我的根文件夹下有一个notfound.html文件，我想使用它作为404 error的页面：
ErrorDocument 404 /notfound.html
假设文件不在站点的根文件夹下，你仅仅须要把路径设置为：
ErrorDocument 500 /errorpages/500.html
注意错误页面的路径一定要正确，否则可能出现：Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
下面是一些最经常使用的错误：
401 – Authorization Required 须要验证
400 – Bad request 错误请求
403 – Forbidden 禁止
500 – Internal Server Error 内部server错误
404 – Wrong page 找不到页面
接下来，你要做的仅仅是创建一个发生错误时显示的文件，然后把它们和.htaccess一起上传。
●禁止显示文件夹列表
有些时候，因为某种原因，你的文件夹里没有index文件，这意味着当有人在浏览器地址栏键入了该文件夹的路径，该文件夹下全部的文件都会显示出来，这会给你的站点留下安全隐患。
为避免这样的情况（而不必创建一堆的新index文件），你能够在你的.htaccess文档中键入下面命令，用以阻止
文件夹列表的显示：
Options -Indexes
●阻止/同意特定的IP地址
某些情况下，你可能仅仅想同意某些特定IP的用户能够訪问你的站点（比如：仅仅同意使用特定ISP的用户进入某个文件夹），或者想封禁某些特定的IP地址（比如：将低级用户隔离于你的信息版面外）。当然，这仅仅在你知道你想拦截的IP地址时才实用，然而如今网上的大多数用户都使用动态IP地址，所以这并非限制使用的经常用法。
你能够使用下面命令封禁一个IP地址：
deny from 000.000.000.000
这里的000.000.000.000是被封禁的IP地址，假设你仅仅指明了当中的几个，则能够封禁整个网段的地址。如你输入210.10.56.，则将封禁210.10.56.0～210.10.56.255的全部IP地址。
你能够使用下面命令同意一个IP地址訪问站点：
allow from 000.000.000.000
被同意的IP地址则为000.000.000.000，你能够象封禁IP地址一样同意整个网段。
假设你想阻止全部人訪问该文件夹，则能够使用：
deny from all
只是这并不影响脚本程序使用这个文件夹下的文档。
●替换index文件
或许你不想一直使用index.htm或index.html作为文件夹的索引文件。举例来说，假设你的网站使用PHP文件，你可能会想使用 index.php来作为该文件夹的索引文档。当然也不必局限于“index”文档，假设你愿意，使用.htaccess你甚至可以设置 foofoo.balh来作为你的索引文档！
这些互为替换的索引文件能够排成一个列表，server会从左至右进行寻找，检查哪个文档在真实的文件夹中存在。假设一个也找不到，它将会把文件夹列表显示出来（除非你已经关闭了显示文件夹文件列表）。
DirectoryIndex index.php index.php3 messagebrd.pl index.html index.htm
●重定向(rewrite)
.htaccess 最实用的功能之中的一个就是将请求重定向到同站内或站外的不同文档。这在你改变了一个文件名，但仍然想让用户用旧地址訪问到它时，变的极为实用。还有一个应用（我发现的非常实用的）是重定向到一个长URL，比如在我的时事通讯中，我能够使用一个非常简短的URL来指向我的会员链接。下面是一个重定向文件的样例：
Redirect /location/from/root/file.ext http: //minidx.com/new/file/location.xyz
上述样例中，訪问在root文件夹下的名为oldfile.html能够键入：
/oldfile.html
訪问一个旧次级文件夹中的文件能够键入：
/old/oldfile.html
你也能够使用.htaccess重定向整个站点的文件夹。假如你的站点上有一个名为olddirectory的文件夹，而且你已经在一个新站点http: //minidx.com/newdirectory/上建立了与上同样的文档，你能够将旧文件夹下全部的文件做一次重定向而不必一一声明：
Redirect /olddirectory http: //minidx.com/newdirectory
这样，不论什么指向到网站中/olddirectory文件夹的请求都将被又一次指向新的网站，包含附加的额外URL信息。比如有人键入：
http: //minidx.com/olddirecotry/oldfiles/images/image.gif
请求将被重定向到：
http: //minidx.com/newdirectory/oldfiles/images/image.gif
假设正确使用，此功能将极其强大。
注：因为Windows Live Writer编辑这篇文章的时候，遇到http:// 就会自己主动加入超级链接，所以上面都特意加了一个空格，而这原本是没有的。
●password保护
虽然有各种各样的.htaccess使用方法，但至今最流行的也可能是最实用的做法是将其用于站点文件夹可靠的password保护。虽然JavaScript等也能做到，但仅仅有.htaccess具有完美的安全性（即訪问者必须知晓password才干够訪问文件夹，而且绝无“后门”可走）。
利用.htaccess将一个文件夹加上password保护分两个步骤。第一步是在你的.htaccess文档里加上适当的几行代码，再将.htaccess文档放进你要保护的文件夹下：
AuthName “Section Name”
AuthType Basic
AuthUserFile /full/path/to/.htpasswd
Require valid-user
你可能须要依据你的站点情况改动一下上述内容中的一些部分，如用被保护部分的名字”Members Area”，替换掉“Section Name”。
/full/parth/to/.htpasswd则应该替换为指向.htpasswd文件（后面详述该文档）的完整server路径。假设你不知道你站点空间的完整路径，请询问一下你的系统管理员。
password保护的.htpasswd文件
文件夹的password保护比.htaccess的其它功能要麻烦些，由于你必须同一时候创建一个包括username和password的文档，用于訪问你的站点，相关信息（默认）位于一个名为.htpasswd的文档里。像.htaccess一样，.htpasswd也是一个没有文件名称且具有8位扩展名的文档，能够放置在你站点里的不论什么地方（此时password应加密），但建议你将其保存在站点Web根文件夹外，这样通过网络就无法訪问到它了。
创建好.htpasswd文档后（能够通过文字编辑器创建），下一步是输入用于訪问站点的username和password，应为：
username:password
“password” 的位置应该是加密过的password。你能够通过几种方法来得到加密过的password：一是使用一个网上提供的permade脚本或自己写一个；另一个非常不错的 username/password加密服务是通过KxS站点，这里同意你输入用户名及password，然后生成正确格式的password。对于多用户，你仅仅须要在.htpasswd文档中新增相同格式的一行就可以。另外另一些免费的脚本程序能够方便地管理.htpasswd文档，能够自己主动新增/移除用户等。
当你试图訪问被.htaccess密码保护的文件夹时，你的浏览器会弹出标准的username/password对话窗体。假设你不喜欢这样的方式，有些脚本程序能够同意你在页面内嵌入username/password输入框来进行认证，你也能够在浏览器的URL框内以下面方式输入username与password（未加密的）：
http://username:password@www.website.com/directory/
●防止盗链
不喜欢别人在的网页上连接的、文档的话，也htaccess的指令来做到。
所的指令例如以下：
RewriteEngine on
RewriteCond %{ HTTP_REFERER } !^$
RewriteCond %{ HTTP_REFERER } !^http://(www.)?mydomain.com/.*$ [NC]
RewriteRule .(gif&line;jpg)$ - [F]
认为让别人的页面开个天窗不好看，那用一张来取代：
RewriteEngine on
RewriteCond %{ HTTP_REFERER } !^$
RewriteCond %{ HTTP_REFERER } !^http://(www.)?mydomain.com/.*$ [NC]
RewriteRule .(gif&line;jpg)$ http://www.mydomain.com/替代名 [R,L]
●其他补充：
在给出怎样配置Apache支持.htaccess文件之前，首先申明一下：使用.htaccess文件，会减少httpdserver的一点性能。
假设须要使用.htaccess以外的其它文件名称，能够用AccessFileName指令来改变。
比如，须要使用.config ，则能够在server配置文件里按下面方法配置：
AccessFileName .config 通常，.htaccess文件使用的配置语法和主配置文件一样。AllowOverride指令按类别决定了.htaccess文件里哪些指令才是有效的。
3、不使用.htaccess文件的场合
普通情况下，不应该使用.htaccess文件，除非你对主配置文件没有訪问权限。有一种非经常见的误解，觉得用户认证仅仅能通过.htaccess文件实现，事实上并非这样，把用户认证写在主配置文件里是全然可行的，并且是一种非常好的方法。
.htaccess文件应该被用在内容提供者须要针对特定文件夹改变server的配置而又没有root权限的情况下。假设server管理员不愿意频繁改动配置，则能够同意用户通过.htaccess文件自己改动配置，尤其是ISP在同一个机器上执行了多个用户网站，而又希望用户能够自己改变配置的情况下。
尽管如此，一般都应该尽可能地避免使用.htaccess文件。不论什么希望放在.htaccess文件里的配置，都能够放在主配置文件的段中，并且更高效。
避免使用.htaccess文件有两个主要原因。
首先是性能。假设AllowOverride启用了.htaccess文件，则Apache须要在每个文件夹中查找.htaccess文件，因此，不管是否真正用到，启用.htaccess都会导致性能的下降。另外，对每个请求，都须要读取一次.htaccess文件。
还有，Apache必须在全部上级的文件夹中查找.htaccess文件，以使全部有效的指令都起作用，所以，假设请求/ctusky/ctu/sky中的页面，Apache必须查找下面文件：
/.htaccess
/ctusky/.htaccess
/ctusky/ctu/.htaccess
/ctusky/ctu/sky/.htaccess
一共就要訪问4个额外的文件，就算这些文件都不存在，这也是本文開始说会影响server的一点性能的原因。
其次是安全。这样会同意用户自己改动server的配置，这可能会导致某些意想不到的改动，所以请认真考虑是否应当给予用户这种特权。
參考文档
http://www.jb51.net/article/25492.htm
http://www.jb51.net/article/25476.htm
