不少网站页面习惯于在URL中的目录名后不加斜杠“/”，这在在apache下会自动添加一个斜杠从而不会造成什么问题，但是如果URL中的二级目录名后不加斜杠的话在Nginx下就会出现403 Forbidden的问题。在网上找到的比较可靠的原因供以想深究的TX进行参考：
在某些情况下（具体可参考 wiki.nginx.org），Nginx 内部重定向规则会被启动，例如，当 URL 指向一个目录并且在最后没有包含“/”时，Nginx 内部会自动的做一个 301 重定向，这时会有两种情况：
1、 server_name_in_redirect on（默认），URL 重定向为： server_name 中的第一个域名 + 目录名 + /；
2、 server_name_in_redirect off，URL 重定向为： 原 URL 中的域名 + 目录名 + /。
当你有多个 域名要指向同一个虚拟主机，并且你自己写 301 重定向规则把它们合并到某一个域名时，情况就更复杂了：
首先，nginx 检查 URL，如果符合条件，就用该规则（你写的）做第一遍重定向，接着，检查新生成的 URL，如果符合内部自动重定向之条件，就用前面提到的规则再做一次重定向。
至于 PHP 的 $_SERVER["SERVER_NAME"]，在 nginx 中默认是由 nginx 的变量 $server_name 提供，这时它和重定向没有关系，始终是 server_name 设置中的第一个域名，但这是可以被改变的，在你的 nginx 配置中找到 fastcgi_param 部分，修改
fastcgi_param SERVER_NAME $server_name;
为
fastcgi_param SERVER_NAME $host;
但 现在就要注意了，此时的 $_SERVER["SERVER_NAME"] 会受你写的和 nginx 自己的重定向规则所影响而变化。
现 在就清楚了，如果 MediaWiki 是通过 $_SERVER["SERVER_NAME"] 来自己处理 URL 的话，那么在 nginx + php 的默认环境下，它获得的将始终是 server_name 设置中的第一个域名，所以造成了“不管通过什么域名访问 MediaWiki 首页，都会被跳转到其中的一个域名上。”，这不是 nginx 的重定向造成的，虽然默认 server_name_in_redirect 是 on，但这个指令的影响范围仅仅只是 nginx 自己内部的重定向规则。
有不少TX可能因为一些原因（比如说天朝的cn域名不停政策变化等）从cn域名转换到了其他域名，但是原来使用的cn域名可能已经积攒了大量的搜索引擎亲和因子,在各大搜索引擎被收录了上万的页面，冒然的直接启用新域名会显得得不偿失。所以这个时候通过一些方法最大可能地保存原来已经有的一些网页资源是势在必行的事情。
对于Google来说可以通过Google提供的网站管理员工具来加快域名转移的速度和效果，关于Google网站管理员工具的操作这里就不赘述了，相关的介绍非常详细。
在执行完前期的网站程序和数据转移之后就需要对原网站进行301的永久重定向，在Apache 下可以通过.htaccess配置RewriteRule，Nginx则在配置文件中加上跟下面类似的一段配置就行：
- server {
- listen 80;
- server_name holmesian.cn www.holmesian.cn;
- if ($http_host !~ ~S^holmesian\.org$~T) {
- rewrite ^(.*) http://holmesian.org$1 permanent;
- }
- }
这里值得一提的是Nginx的 Rewrite Flags：
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301
测试一下，现在从搜索引擎来的holmesian.cn和www.holmesian.cn都被直接转成holmesian.org，用户几乎没有任何察觉。接下来等待搜索引擎响应了……估计这个会有一个周期。
DeDe CMS是一个由PHP编写功能强大的开源CMS系统，经过了长时间不断磨合，现在已经是一款比较完善开源CMS系统。
最新版的DeDeCMS提供对每篇文章的关键字自动提取功能，但是经过实际使用之后发现UFT-8版的关键字自动提取功能实在是不敢恭维，所以想到用tag替换关键的办法。
具体操作方法：修改相应文章模板文件，找到
- <meta name="keywords" content="{dede:field.keywords/}" />
改成
- <meta name="keywords" content="{dede:tag row='6'}[field:tag /],{/dede:tag}">
上传修改的文件后重新生成页面即可
终于解决FreeBSD下Nginx做前端 FastCGI的PHP出现问题的情况了，原因很囧
过程如下：
ecjtu# whereis php-cgi
php-cgi: /usr/local/bin/php-cgi
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -f /usr/local/php/bin/php-cgi
spawn-fcgi: child exited with: 127
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -u www -f /usr/local/bin/php-cgi
spawn-fcgi: child exited with: 13
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -U www -f /usr/local/bin/php-cgi
spawn-fcgi: child spawned successfully: PID: 39766
现在OK了
莫非127错误是php-cgi位置错误 13错误是大写U写成了小写u
服务器操作系统：FreeBSD7
前端Nginx 后端Apache22（通过FreeBSD的Ports安装）
这段时间服务器老是提示Nginx 502 Bad Gateway错误，经检查前端Nginx正常，后端Apache卡死，拒绝一切连接。必须重启后端Apache才能
查询日志有如下内容
网上搜索说是在FreeBSD下使用ports安装apache22会出现类似的warming：
Failed to enable the 'httpready' Accept Filter 据说这是Apache21和FreeBSD之间Bug！ 解决方法是： 并在/boot/defaults/loader.conf中添加如下内容，以便下次启动自动装载模块
#kldload accf_http
accf_data_load="YES"
accf_http_load="YES"
Apache会卡死是因为FreeBSD自带的一个基于http端口过滤的模块不能加载。这个模块的作用是检查HTTP请求是否完整，如果请求是符合规则的则通过，反之就扔掉。
错误类型一：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver] 不能更新。
错误类型二：
Microsoft OLE DB Provider for ODBC Drivers 错误 ''80004005''
[Microsoft][ODBC Microsoft Access Driver]常见错误 不能打开注册表关键字 ''Temporary (volatile) Jet DSN for process 0x728 Thread 0x854 DBC 0x276fb44 Jet''。
- Set conn=Server.CreateObject("ADODB.Connection")
- conn.open ConnStr
- conn.execute "Insert Into Vote_List(Project,MultiSelect,Vote_Limit) Values('"&txt1&"',"&mul&",'"&request("times")&"')"
错误类型一：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver] 不能更新。
错误类型二：
Microsoft OLE DB Provider for ODBC Drivers 错误 ''80004005''
[Microsoft][ODBC Microsoft Access Driver]常见错误 不能打开注册表关键字 ''Temporary (volatile) Jet DSN for process 0x728 Thread 0x854 DBC 0x276fb44 Jet''。
最近周围TX的电脑都因为下载某些软件导致系统的桌面和IE乱七八糟
比较多的情况有这么两种：
1、在WindowsXP系统下 恶意软件导致系统桌面多出一个IE图标：点开那个IE图标会打开一个网址导航站 你想删除这个IE图标就会弹出IE属性 各种常规的删除方法都不能将这个IE图标删除
2、在Windows7系统下 恶意软件导致Windows7的库丢失：这个时候点击任务栏的任务图标要么是出来导航站 要么是是出来任务管理器 总之库就是永久丢失了
Blog.ecjtu.net的问题已经出了好几天了，一直没有时间仔细去研究。具体问题体现在某些用户的博客首页无法打开，而大部分有可以正常打开，最近这两天听博客管理员说报告类似错误的用户越来越多所以今天就仔细的找了一下原因。
博客系统使用的是SupeSite/X-Space由Ucenter和论坛整合，服务器是FreeBSD，前端Nginx，后端Apache跑php(暂时这样，准备年后换FastCGI)。
用IE6访问全站正常，用非IE6的浏览器，如IE7、IE8、FireFox、Chrome等浏览器打开时都无法打开部分用户的首页，提示内容如下
