@leaf 腾讯企业邮还有一个恶心我的地方就是二次验证，居然要用微信！我一直以来都没有使用微信的习惯，为了二次验证还要我特意安装个差不多30 Mbytes的APP，一个微信帐号只能绑定一个企业邮箱帐号，接收验证码要联网，什么鸡肋东西……
更难受的是还要后台自启动！

@leaf 说起导出我就生气，那天我要在腾讯企业邮删除一个邮箱，于是创建了另一个邮箱，删除邮箱时选择备份到另一个邮箱，删除是删除成功了，但登入新的邮箱，看到一封邮件：“您有部分邮件无法备份”，内容其中是：邮件总数22315封，成功备份0封，失败0封。

更气人的是，两周前我给网易反馈一个邮箱的安全问题，他们不理我，于是我这周发布到乌云，结果乌云居然说：“产品线不同造成，很多产品都有这个情况，行业问题，望见谅”。为什么不见Gmail有这情况？

我已经决定放弃国内的邮箱服务了，功能，安全方面都不让我满意，部分重要的帐号的邮箱已经更改为Gmail了，毕竟我是良民，凌镜计划对我来说无任何威胁，至于天朝的情况麻，我就不作评论，这周放假回家把余下的改完。

@leaf 登录腾讯企业邮箱，删除掉已经绑定的那个域名。

@leaf 的确有影响，你要知道发件人的地址是任发件人说的，既然那个域名已经绑定到腾讯企业邮了，那就等于告诉腾讯企业邮他们才是那个域名的合法使用者，来自外部服务器，且宣称使用该域名的都是在伪造身份。

是不是发件人的域名已经在腾讯企业邮箱处绑定？

@nonozone 貌似IP是183开头的节点宕机了。
刚刚删掉183的DNS记录了，有几个DNS记录的TTL是3600，可能没生效，你用nslookup看另外一个122开头的IP，然后更改hosts再访问吧。

@extreme 跨站几乎是不可能的前提是你使用Linux KIT的Shell Script添加站点时给每个站点设置了不同的用户。

@nonozone 应该每个网站都以不同的域名访问吧？让每个网站的PHP都以各自的身份运行就行了。
Apache的用mod_php的可以用mod_itk或mod_ruid2。
FastCGI我没用，不了解。
Nginx With PHP FPM的话，给每个网站都建立一个pool，并且以不同的用户身份启动。
把各网站的文件的所有者更改为PHP执行用户就行了，mod_php的可以给700权限，如果用Apache with FastCGI或PHP FPM，则需要把Apache或Nginx的执行用户加入各PHP执行用户的用户组中，网站文件权限设置为750。

有些地方我不知道如何表达才能让你更好理解，不知道你能不能看明白……
你可以考虑使用我的Linux KIT: http://linuxk.it/，只要你不乱改文件权限，跨站几乎是不可能事件，推荐在Debian 7使用Linux KIT。

不清楚楼主所说的处于同一目录是什么意思。
那同处在/算不算是在同一个目录？
要别人帮助你解决问题，那就必须说得清楚一点。
是多个网站程序同时放在某个目录，抑或是多个网站分别放在同一个目录中不同的子目录？
还有如何访问？只给网站根目录绑定了域名，访问不同网站时加上子目录名称？抑或不同网站使用不同的域名？

以我的看法，那些把时间扯进“维”里面的完全就是错误的(@zld ) 。
时间并非自然界的东西，仅是我们意识上的，有了意识，才会有时间(不要谈唯x主义，有就有，没就没)。

不应该把“维”复杂化的。
简单来说，“维”是对运动方式的一种描述，静止状态的事物，可以说他处于零维；可以前后运动的事物，则为一维；不仅可前后运动，还可左右运动，则是二维；可以前后左右上下运动的，则是三维。
所谓的四维，以及更高的维，仅是一些以我们目前的大脑所无法理解的运动方式。

@bingu I prefer VIM.

@ooxxcc 之前用Windows XP，开始自己开网站前就没用IE了，不太了解。
可以用正则表达式判断一下$http_user_agent。

为什么Windowd XP不支持SNI？
Windows XP也不会落后到HTTP请求不带hosts吧。
支不支持SNI目前主要取决于HTTP Server了，Nginx不就是通过HTTP请求头中host的内容判断用哪个站点SSL证书的吗？

为什么不采用验证码方式呢？
你确定是带宽被占满，而不是物理内存与CPU吗？

@ryd994 这是针对一个问题的多种解决方案。

我觉得准确点，应该是CC攻击。
要对抗云盾都防不住的CC攻击，那就得做出一点牺牲了。
访客访问网站，首先检查Cookie中有没有SessionID，没有的话就302重定向至一个页面，要求输入验证码，正确后就生成一个Session，Set Cookie,Cookie中带Session ID，Sssion中保存访客的IP，并生成一串随机字符，然后Set一个Cookie，内容为随机字符。

已有Session的访客，每次访问就检查Session中的IP是否与访客的IP一致，否就302到验证码页面，要求重新验证。
IP检查通过后，就检查Cookie中的随机字符是否与Session中的随机字符匹配，否就302到验证码页面要求重新验证，匹配的话，就重新生成一串随机字符到Session，并且重新Set随机字符的Cookie。

这样做非常有效，但会影响搜索引擎的抓取，不过总比被CC到宕机无法访问好。