my blog my blog

Tag: Nginx
一个openai的ChatGPT反向代理实现

在奶牛看来,用api的同时保护自己不被暴露的安全性是最重要的。ChatGPT最近老火了,虽然奶牛还没用上4.0,一直在排队,但是也写点儿东西来弥补一下这个曾经没什么作品的遗憾吧。一直以来都没有发不过什么作品,这次写了个docker来实现这个反代。以OpenResty,通过lua来做安全验证防护,通过Nginx的proxy来反代。

使用方法:

docker pull nenew/openai-api
docker run -itd --name api-server -p 127.0.0.1:811:80 nenew/openai-api

你的openai反代地址: http://127.0.0.1:811
通过绑定到本地端口,可以阻止服务器被公众访问。
如果想让你的api反代服务器被公开,你也可以通过-e选项来绑定一个可以访问的IP或者设置一个密码来保证只有自己可以使用。

docker run -itd --name api-server -p 811:80 -e BIND_IP="123.123.123.123" nenew/openai-api
docker run -itd --name api-server -p 811:80 -e SECRET="Your secret" nenew/openai-api

注意:如果你设置了SECRET环境变量,你还需要设置你的app的请求头,增加X-Secret来完成验证:

X-Secret:Your secret

 测试:

访问 http://127.0.0.1/status 你可以看到你的请求头、请求体、设置的IP、设置的密码以及响应头的具体信息.
你也可以设置你的app的api到这个页面来进行测试或者使用Nginx的proxy_pass来设置转发。

proxy_pass http://1277.0.0.1/status

为什么你的反代不安全

其实写这个docker的原因很简单,看到很多不安全因素存在在你们的自建api里面。
首先你们没有去掉或者掩盖[“X-Real-IP”]和[“X-Forwarded-For”]。
反向代理的作用是保护目标服务器,但是我们其实想通过反代保护我们自己来保障我们的app可以正常的访问,所以完全没有必要把我们的X-Real-IP和X-Forwarded-For给目标服务器。我们建立反代其实目的是建立一个正向代理。这两个参数明显会暴露我们自己的真实IP,造成api的key多人使用的问题。
其次,很多人自建的api谁都可以用,比如像那些利用serverless实现的反代,你的访问IP地址每次都可能变化,那样子你的api key很可能就被判定为滥用【remote_addr一直是变化的】。我这个docker可以通过设置绑定IP和SECRET来阻止外界访问。
我认为最安全的方案应该是:
把这个docker放在你的独立服务器或者VPS上,你可以设置你的web app也在同一台服务器上,当然你也可以设置你的app来通过加密或者绑定IP的方式来达到隐藏自己的目的。

使用Nginx Lua阻止对服务器IP的80/443端口直接访问

Lua作为Nginx服务器的脚本扩充非常好用,而且性能也很好。如果要使用Nginx Lua阻止对服务器IP的80/443端口直接访问,我们可以对nginx.conf进行如下设置

location / {
access_by_lua_block{
	if ( ngx.var.host ~= "www.nenew.net" ) then 
		ngx.exit(444)
	end
                    }
             }

其中的ngx.var.host代表目标域名,有几个变量可能会发生混淆:

ngx.var.server_name对应server_name:www.nenew.net
ngx.var.host对应host:test1.nenew.net
ngx.var.hostname对应hostname:nenew

这里我们就看啊,如果我们把IP绑定给其它域名,或者对方直接用hosts来进行dns解析,改变的是ngx.var.host,这个是访问者的目标域名,是变化的,所以这里block是针对的ngx.var.host,只要判定不相同即无法访问,我们直接给一个444状态,切断连接不响应。hostname是主机名,这里没有什么用,ngx.var.server_name变量是绑定域名,不能用绑定域名来判定,因为绑定域名会变,但是访问域名可能会造成改变。

Nginx配置noVNC的web页面教程

先说下noVNC的一键启动

./utils/launch.sh --listen localhost:6002--vnc localhost:6001

listen是监听本地端口,如果开放就不要用localhost而用0.0.0.0就好了 。vnc后面是vnc server的端口。

这个noVNC的启动项目没法直接用Nginx反代,因为涉及到websocket。官方的教程是这样做的

在nginx.conf的http字段中添加
upstream vnc_proxy {
    server 127.0.0.1:6080;
}
在nginx.conf的server字段中添加
location /websockify {
          proxy_http_version 1.1;
          proxy_pass http://vnc_proxy/;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";

          # VNC connection timeout
          proxy_read_timeout 61s;

          # Disable cache
          proxy_buffering off;
    }
location /vnc {
            index vnc.html;
            alias /home/nenew/noVNC/;
            try_files $uri $uri/ /vnc.html;
    }

其实很好理解,就是通过建立nginx和upstream的连接,然后把vnc的传输通过websocket完成。

这里nginx配置就算完成了,我们还需要一个websocket

./utils/websockify/run source_port target_addr:target_port

其中的源端口和目标地址:端口就正常填写即可,这里需要说的是目标端口和一键启动的端口没有关系,就是vnc的服务端口,websockify和launch俩程序没啥关系。

然后直接通过网站http://www.nenew.net/vnc访问即可。

CloudFlare CDN下Nginx正确获取真实IP教程

说到获取真实IP,我们不难想到nginx的http realip module,就是当遇到IP是设定范围内的地址时,就逆向递归获取源目标的真实IP。对于Cloudflare CDN而言,也是遵从行业标准的,即使用X-Forwarded-For header 和 CF-Connecting-IP header 。Cloudflare的真实IP地址可以从这里获取Cloudflare IP addresses,当然我们也可以查看文本格式的Cloudflare的IP段:

https://www.cloudflare.com/ips-v4
https://www.cloudflare.com/ips-v6

官方建议还是要定期更新这个IP范围的,以免范围改动影响使用效果。

奶牛找到了一个别人写好的sh脚本,可以自动生成一个Cloudflare真实IP的conf。

#!/bin/bash
echo "#Cloudflare" > /usr/local/nginx/conf/cloudflare_ip.conf;
for i in `curl https://www.cloudflare.com/ips-v4`; do
        echo "set_real_ip_from $i;" >> /usr/local/nginx/conf/cloudflare_ip.conf;
done
for i in `curl https://www.cloudflare.com/ips-v6`; do
        echo "set_real_ip_from $i;" >> /usr/local/nginx/conf/cloudflare_ip.conf;
done
echo "" >> /usr/local/nginx/conf/cloudflare_ip.conf;
echo "# use any of the following two" >> /usr/local/nginx/conf/cloudflare_ip.conf;
echo "real_ip_header CF-Connecting-IP;" >> /usr/local/nginx/conf/cloudflare_ip.conf;
echo "#real_ip_header X-Forwarded-For;" >> /usr/local/nginx/conf/cloudflare_ip.conf;

运行脚本后,我们可以得到一个/usr/local/nginx/conf/cloudflare_ip.conf的conf文件,在网站所在的nginx conf中添加字段:

include /usr/local/nginx/conf/cloudflare_ip.conf;

即可,添加完成后使用nginx t来验证配置文件是否正确,正确无误后重启或者重新载入nginx即可。

也可以使用cron计划任务来定期更新cloudflare_ip.conf文件。

0 5 * * 1 /bin/bash /location/to/update_cf_ip.sh

这样子就可以在每周1的5点进行自动更新Cloudflare的IP conf文件了。如果使用配置文件中的X-Forwarded-For参数,理论上对所有的执行标准的CDN都是有效的。

使用ab在linux下进行网站压力测试

ab是apache自带的压力测试工具。ab非常实用,它不仅可以对apache服务器进行网站访问压力测试,也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等。原理就是模拟并发请求访问指定次数,如果并发很大就相当于cc攻击了。

安装:我们当然不要安装一整套apache来用这么一个工具了,只安装相应套件就可以了。

sudo apt-get install apache2-utils  
sudo yum -y install httpd-tools

在ubuntu里面用apache2-utils,在centos里面用httpd-tools.

测试:

ab -n 1000 -c 10 https://www.xxx.com/

其中-n是指定总的访问次数,总的访问次数,总的访问次数,重要的事儿说三遍。

-c是指定并发数。

https://www.xxx.com/后面的/不能省略,或者需要指定完整的页面路径

上面命令的解释就是用10个并发访问https://www.xxx.com/,每个并发访问100次,总共访问了1000次。

自己玩儿了下,发现缓存插件真的能有效降低cpu的压力,提高网站性能,如果不用缓存cpu占用率简直不要飞到天上去。

通过nginx配置文件抵御CC攻击,防御99%的CC攻击

大家好,我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。

其实很多时候,各种防攻击的思路我们都明白,比如限制IP啊,过滤攻击字符串啊,识别攻击指纹啦。可是要如何去实现它呢?用守护脚本吗?用PHP在外面包 一层过滤?还是直接加防火墙吗?这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。

0x01 验证浏览器行为

简易版

我们先来做个比喻。

社区在搞福利,在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包,聪明工作人员需要想出办法来防止红包被冒领。

于是工作人员在发红包之前,会给领取者一张纸,上面写着“红包拿来”,如果那人能念出纸上的字,那么就是人,给红包,如果你不能念出来,那么请自觉。于是机器人便被识破,灰溜溜地回来了。

是的,在这个比喻中,人就是浏览器,机器人就是攻击器,我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。

if ($cookie_say != "hbnl"){
     add_header Set-Cookie "say=hbnl";
     rewrite .* "$scheme://$host$uri" redirect;
}

让我们看下这几行的意思,当cookie中say为空时,给一个设置cookie say为hbnl的302重定向包,如果访问者能够在第二个包中携带上cookie值,那么就能正常访问网站了,如果不能的话,那他永远活在了302中。你也可以测试一下,用CC攻击器或者webbench或者直接curl发包做测试,他们都活在了302世界中。

当然,这么简单就能防住了?当然没有那么简单。

增强版

仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl(CC攻击器上就可以这么设置),那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。

坏人发现这个规律后,给每个机器人安上了扬声器,一直重复着“红包拿来,红包拿来”,浩浩荡荡地又来领红包了。

这时,工作人员的对策是这样做的,要求领取者出示有自己名字的户口本,并且念出自己的名字,“我是xxx,红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。

当然,为了配合说明问题,每个机器人是有户口本的,被赶回去的原因是不会念自己的名字,虽然这个有点荒诞,唉。

然后,我们来看下这种方式的配置文件写法

if ($cookie_say != "hbnl$remote_addr"){
     add_header Set-Cookie "say=hbnl$remote_addr";
     rewrite .* "$scheme://$host$uri" redirect;
}

这样的写法和前面的区别是,不同IP的请求cookie值是不一样的,比如IP是1.2.3.4,那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下,你会发现CC攻击器打出的流量已经全部进入302世界中。

不过大家也能感觉到,这似乎也不是一个万全之计,因为攻击者如果研究了网站的机制之后,总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息(IP、user agent等)。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。

完美版

那么要如何根据他们自身的信息得出他们又得出他们算不出的数值?

我想,聪明的你一定已经猜到了,用salt加散列。比如md5(“opencdn$remote_addr”),虽然攻击者知道可以自己IP,但是他无法得知如何用他的IP来计算出这个散列,因为他是逆不出这个散列的。当然,如果你不放心的话,怕cmd5.com万一能查出来的话,可以加一些特殊字符,然后多散几次。

很可惜,nginx默认是无法进行字符串散列的,于是我们借助nginx_lua模块来进行实现。

rewrite_by_lua '
     local say = ngx.md5("opencdn" .. ngx.var.remote_addr)
     if (ngx.var.cookie_say ~= say) then
         ngx.header["Set-Cookie"] = "say=" .. say
         return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)
     end
';

通过这样的配置,攻击者便无法事先计算这个cookie中的say值,于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。

大家可以看到,除了借用了md5这个函数外,其他的逻辑和上面的写法是一模一样的。因此如果可以的话,你完全可以安装一个nginx的计算散列的第三方模块来完成,可能效率会更高一些。

这段配置是可以被放在任意的location里面,如果你的网站有对外提供API功能的话,建议API一定不能加入这段,因为API的调用也是没有浏览器行为的,会被当做攻击流量处理。并且,有些弱一点爬虫也会陷在302之中,这个需要注意。

同时,如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话,你可以把上述的通过header来设置cookie的操作,变成通过高端大气的js完成,发回一个含有doument.cookie=…的文本即可。

那么,攻击是不是完全被挡住了呢?只能说那些低级的攻击已经被挡住而来,如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行set-cookie才行,那么他也是可以逃脱302地狱的,在nginx看来,确实攻击流量和普通浏览流量是一样的。那么如何防御呢?下节会告诉你答案。

0x02 请求频率限制

不得不说,很多防CC的措施是直接在请求频率上做限制来实现的,但是,很多都存在着一定的问题。

那么是哪些问题呢?

首先,如果通过IP来限制请求频率,容易导致一些误杀,比如我一个地方出口IP就那么几个,而访问者一多的话,请求频率很容易到上限,那么那个地方的用户就都访问不了你的网站了。

于是你会说,我用SESSION来限制就有这个问题了。嗯,你的SESSION为攻击者敞开了一道大门。为什么呢?看了上文的你可能已经大致知道了,因为就像那个“红包拿来”的扬声器一样,很多语言或者框架中的SESSION是能够伪造的。以PHP为例,你可以在浏览器中的cookie看到PHPSESSIONID,这个ID不同的话,session也就不同了,然后如果你杜撰一个PHPSESSIONID过去的话,你会发现,服务器也认可了这个ID,为这个ID初始化了一个会话。那么,攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请求次数限制。

那么我们要如何来做这个请求频率的限制呢?

首先,我们先要一个攻击者无法杜撰的sessionID,一种方式是用个池子记录下每次给出的ID,然后在请求来的时候进行查询,如果没有的话,就拒绝请求。这种方式我们不推荐,首先一个网站已经有了session池,这样再做个无疑有些浪费,而且还需要进行池中的遍历比较查询,太消耗性能。我们希望的是一种可以无状态性的sessionID,可以吗?可以的。

rewrite_by_lua '

     local random = ngx.var.cookie_random

     if(random == nil) then
         random = math.random(999999)
     end

     local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
     if (ngx.var.cookie_token ~= token) then
         ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}
         return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)
     end
';

大家是不是觉得好像有些眼熟?是的,这个就是上节的完美版的配置再加个随机数,为的是让同一个IP的用户也能有不同的token。同样的,只要有nginx的第三方模块提供散列和随机数功能,这个配置也可以不用lua直接用纯配置文件完成。

有了这个token之后,相当于每个访客有一个无法伪造的并且独一无二的token,这种情况下,进行请求限制才有意义。

由于有了token做铺垫,我们可以不做什么白名单、黑名单,直接通过limit模块来完成。

http{
     ...
     limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;
}

然后我们只需要在上面的token配置后面中加入

limit_req zone=session_limit burst=5;

于是,又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷,因为攻击者可以通过一直获取token来突破请求频率限制,如果能限制一个IP获取token的频率就更完美了。可以做到吗?可以。

http{
     ...
     limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;
     limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m;
}

location /{

     limit_req zone=session_limit burst=5;
     rewrite_by_lua '
     local random = ngx.var.cookie_random
     if (random == nil) then
         return ngx.redirect("/auth?url=" .. ngx.var.request_uri)
     end
     local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
     if (ngx.var.cookie_token ~= token) then
         return ngx.redirect("/auth?url=".. ngx.var.request_uri)
     end
';

}

location /auth {
     limit_req zone=auth_limit burst=1;

     if ($arg_url = "") {
         return403;
     }

     access_by_lua '
         local random = math.random(9999)
         local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
         if (ngx.var.cookie_token ~= token) then
             ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}
             return ngx.redirect(ngx.var.arg_url)
         end
     ';
}

我想大家也应该已经猜到,这段配置文件的原理就是:把本来的发token的功能分离到一个auth页面,然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然,这个数量可以根据业务需要进行调整。

需要注意的是,这个auth部分我lua采用的是access_by_lua,原因在于limit模块是在rewrite阶段后执行的,如果在rewrite阶段302的话,limit将会失效。因此,这段lua配置我不能保证可以用原生的配置文件实现,因为不知道如何用配置文件在rewrite阶段后进行302跳转,也求大牛能够指点一下啊。

当然,你如果还不满足于这种限制的话,想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话,也是可以的,你可以用类似的思路再做个错误页面,然后到达上限之后不返回503而是跳转到那个错误页面,然后错误页面也做个请求次数限制,比如每天只能访问100次,那么当超过报错超过100次(请求错误页面100次)之后,那天这个IP就不能再访问这个网站了。

于是,通过这些配置我们便实现了一个网站访问频率限制。不过,这样的配置也不是说可以完全防止了攻击,只能说让攻击者的成本变高,让网站的扛攻击能力变强,当然,前提是nginx能够扛得住这些流量,然后带宽不被堵死。如果你家门被堵了,你还想开门营业,那真心没有办法了。

然后,做完流量上的防护,让我们来看看对于扫描器之类的攻击的防御。

0x03 防扫描

ngx_lua_waf模块

这个是一个不错的waf模块,这块我们也就不再重复造轮子了。可以直接用这个模块来做防护,当然也完全可以再配合limit模块,用上文的思路来做到一个封IP或者封session的效果。

0x04 总结

本文旨在达到抛砖引玉的作用,我们并不希望你直接单纯的复制我们的这些例子中的配置,而是希望根据你的自身业务需要,写出适合自身站点的配置文件。

 

这篇文章并不是奶牛原创的,但是奶牛觉得非常好,之前应该是发布在乌云上面的,但是乌云现在已经人去楼空了,希望这篇很好的文章可以保存下来。

Ubuntu安装配置Linux性能实时监测工具NetData

最近测试了ntopng,虽然普通版本的也还凑合,但是还是企业版的实时展示奶牛更喜欢,可是普通版本就没有实时功能了,所以就又找了一下,发现在github上这个netdata的star最多,目前已经达到了28.9K,感兴趣的朋友可以去https://github.com/topics/monitor看看。

言归正传,奶牛来说说netdata的安装过程。

安装:

curl -Ss 'https://raw.githubusercontent.com/firehol/netdata-demo-site/master/install-required-packages.sh' >/tmp/kickstart.sh && bash /tmp/kickstart.sh -i netdata-all

安装netdata编译所需组件,这里奶牛以全监控安装方式安装

git clone https://github.com/firehol/netdata.git --depth=1
cd netdata
./netdata-installer.sh --dont-start-it

这里根据提示进行安装即可,安装完成后我们可以通过service netdata start 来启动。

配置:

这里有个有趣的现象,在/etc/netdata/netdata.conf文件中并没有配置选项,而是需要从web下载配置文件,当然这个web是localhost了。

#  wget -O /etc/netdata/netdata.conf http://localhost:19999/netdata.conf
#  curl -o /etc/netdata/netdata.conf http://localhost:19999/netdata.conf

所以呢,就按照这个说明把netdata.conf文件下载下来就可以配置了。

在此,奶牛更希望我们以反向代理的方式进行访问netdata,所以奶牛并不推荐直接将netdata端口暴露出来,所以我们将netdata.conf文件中的

[web]
	bind to = 127.0.0.1

修改为绑定到本地地址。最后我们可以通过Nginx反向代理来进行访问,或者如果你不介意,不这样配置也无所谓。

Nginx强制http跳转至https

奶牛启用https后发现还是在http和https共存的时候出现一些小问题,遂决定使用Nginx强制跳转https。

vim /usr/local/nginx/conf/vhost/nenew.net.conf

在配置文件的listen 80这段中插入语句

rewrite ^(.*)$  https://www.nenew.net$1 permanent;

然后重启Nginx即可。

Ubuntu安装goaccess进行Nginx日志分析

今天测试了一下goaccess,但是感觉并没有想像的那么好,也没详细考证config文件的配置,就默认配置来说,可能奶牛想要的关键词统计并没有在上面,好吧,还是记录一下安装过程吧。这里奶牛以Ubuntu server为例,以Nginx作为web服务器进行配置。

apt-get install libncursesw5-dev libgeoip-dev
mkdir goaccess
wget http://tar.goaccess.io/goaccess-1.2.tar.gz
tar -xzvf goaccess-1.2.tar.gz
cd goaccess-1.2/
./configure --enable-utf8 --enable-geoip=legacy
make
make install

这里我们就完成了goaccess的安装,下面进行config文件的更改,位置为/usr/local/etc//goaccess.conf

vim /usr/local/etc/goaccess.conf
log-format COMBINED

将log文件的格式设置为COMBINED。

最后goaccess就可以使用了。在wwwlogs目录下

goaccess access.log -o report.html

然后我们就可以通过report.html来查看统计信息了。

 

关于bench.sh网站的实现

最近看到一条命令很有意思,一起来和大家解读一下,这个网站就是bench.sh

可能搞VPS的朋友很熟悉一条命令

wget -qO- bench.sh | bash

用这条命令可以直接实现linux下运行bench.sh的命令,刚开始奶牛也挺疑惑的,难道wget还自带这种功能,其实不然,命令中的bench.sh是个网站,对,是个网站,访问网站我们可以看到如下提示:

嗨!欢迎使用 Bench.sh

你可以使用以下命令来查看您的 Linux 系统信息,还可以测试网络带宽及硬盘读写速率

wget -qO- bench.sh | bash

或者

curl -Lso- bench.sh | bash

有意思的事儿发生了对么?为什么我们访问网站和我们wget得到的效果不同?因为网站对于user agent进行了识别。如果我们在命令行中执行

wget -O- bench.sh

我们可以看到如下结果:

Resolving bench.sh (bench.sh)... 149.202.55.78
Connecting to bench.sh (bench.sh)|149.202.55.78|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://86.re/bench.sh [following]
Resolving 86.re (86.re)... 104.224.156.154
Connecting to 86.re (86.re)|104.224.156.154|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7017 (6.9K) [application/x-sh]
Saving to: 'STDOUT'

好了,我们看到了一个302的字眼,这个是通过重定向来实现的,直接将使用wget和curl的user agent重定向到了http://86.re/bench.sh这个文件,所以我们wget或者curl得到的是这个文件。这里奶牛猜测原作者应该是用rewrite来写的,直接用web服务器进行ua判定之后rewrite到了这个文件。

奶牛的文章到这里并没有结束,来想想还除了rewrite还有没有其它的实现方法?奶牛感觉还有至少两种实现方法,反代可以实现,还有直接在服务器内进行根目录的重定向也可以实现。奶牛就把后者的实现过程来说一下。web服务器奶牛用的nginx。对网站conf进行配置修改:

server
    {
        listen 80;
        #listen [::]:80;
        server_name bench.2fu.org ;
        set $target bench.2fu.org ;
        if ( $http_user_agent ~* "(wget)|(curl)" )
        {
                set $target bench.2fu.org/true ;
        }
        index index.html index.htm index.php default.html default.htm default.php;
        root  /home/wwwroot/$target;

        include none.conf;
        #error_page   404   /404.html;

        # Deny access to PHP files in specific directory
        #location ~ /(wp-content|uploads|wp-includes|images)/.*\.php$ { deny all; }

        include enable-php.conf;

        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires      30d;
        }

        location ~ .*\.(js|css)?$
        {
            expires      12h;
        }

        location ~ /.well-known {
            allow all;
        }

        location ~ /\.
        {
            deny all;
        }

        access_log  /home/wwwlogs/bench.2fu.org.log;
    }

然后将true目录下建立一个index.html然后内容就是bench.sh。这样实现的效果是:

Resolving bench.2fu.org (bench.2fu.org)... 
Connecting to bench.2fu.org (bench.2fu.org)|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7017 (6.9K) [text/html]
Saving to: 'STDOUT'

没有302,奶牛更喜欢200 OK 。其实nginx服务器要是折腾折腾配置也很有意思。