一、楔子
V2ray客户端更新，新年开始淘汰Vmess的md5验证算法，加上折腾了梅林路由系统发现vmess只能跑个20mbps，终于有了些动力关注下最新的Vless协议和新的Xtls黑科技。
说实话，从我个人习惯和对协议伪装的理解来说，Vmess+websockets+tls这种模式，是易于理解并且可靠朴素的。但是技术更新那么快，多少了解下新形势还是非常有必要的。
Vless 相对于Vmess少了些什么？
少了在tls加密下对数据的第二层加密，充分依赖tls的伪装可靠性，在tls的包裹下快乐裸奔tcp数据，也就是普通的http明文数据
Xtls又为何称为extreme TLS？
技术层面上不懂，但是据说大佬将其搭配Vless协议做到了直接接手nginx路由分发角色，同时无缝处理到位vless的加密流量和普通的tls加密流量，从而让full cone也成为可能
更高的响应分发效率，去掉了没必要的再次数据加密，从而在路由系统和手机端能节省大量cpu和内存性能，在低端客户端环境下，会有极大的带宽提升体验，看起来很值得我去尝试下
普通的Vmess +ws+tls转换为Vless+ws+tls的话很简单，基本上用v2ray新版就可以做到，v2ray依然做后端接收nginx通过path传递过来的数据，去掉alterID项，修改加密模式vmess为vless，基本上就行
而主推的vless搭配模式则是将nginx和之前vmess角色对调，让vless在第一线进行数据识别分发，然后按着alpn或者path来进行包裹分拣，path下发后下沉分配到对应协议组合，如vmess加密数据，或者trojan数据，而alpn识别分发通过fallback回落到对应的nginx以及其他端口的伪装代理。
二、批判
vless的野心，xtls的狂妄，可以看出开发者的热血和踌躇满志，然而经过我三天的折腾，一个通宵加废寝忘食研究后发现，官方对nginx和建站正常运转的忽视，以及大量的文档过期将近1年的疏于维护，我隐约看到，真正的程序员那种挑灯夜战，只为真理和极致，在市场运营方面为何没有地位了。
作为一个用户，对于一个开源产品唧唧歪歪，没有任何贡献进行指点江山，我确实是在做宵小之辈的事情。
我没有任何资格可以指责，但是我实在忍不住想谈谈这种开发者的断层问题，你要理解为我针对谁，那也行吧
用户到底需要什么？
稳定
既是协议可靠上的稳定，也是学习更新上手的稳定
别的不说，跟随v2ray项目衍生的windows客户端v2rayN，多次更新的体验，就让人左右不适。
不提之前各种版本漏洞没有任何通知，全靠自己github和朋友信息圈子奔走相告，对于最基本的用户，浑然不觉自己已然是裸奔
后面更新的路由协议规则变成规则集，简直让用户束手无策。可能是觉得大家用习惯的右键>>>选择服务器>>展开服务器列表>>选择合适的服务器>>>再进行系统配置选择
这种繁琐的事情已经没有任何挑战了，再给你搞一套路由规则，甚至里面没有国外vps访问国内站点默认的仅代理国内ip之类的傻瓜预设，这是三组参数里面自己慢慢调整，字面上对于新手来说还模棱两可
优秀的销售从不让你做任何选择，而是帮你做选择
这尼玛让人A33排列组合一阵之后发现不爽，还得help myself自己动手，打开自定义设置一看，菜单都完全变样了，这规则集我要它何用，我就是要让自己个人想代理的几个域名加入代理列表，仅此而已，规则集也没有个直接添加规则的按钮，还得导入做好的文档，瞬间失去兴致，卸载重新用旧版本了
依稀记得10年前有一款似乎叫诺顿 vpn啥的，自动帮你选择最优节点，整个界面就是一个大大的按钮，点一下，就连通，变绿色，点关闭，就红色，停止工作，对于太多的用户来说，他们要用你了，你动一动干活了，就行了
三、真实故事
说到这想起一个mjj说的真实故事，他一顿操作给他的女朋友还是女同事搞定了iplc warp disney+ Netflix一条龙服务，节点双手奉上，v2rayNG帮忙配置完毕。
“教会”了他的那个她怎么看片，结果第二天她就蹦蹦跳跳过来不好意思地问，为什么今天用不了了
“你先启动v2rayNG，就是那个黑色的V字app，然后就可以看视频了”
“我启动了呀”
某mjj迅速自查一番所有节点发现都正常没被墙，然后劈里啪啦打字回复“不应该啊，你怎么启动的，流程详细说说”
“就是你教我的，先点开V，然后就可以打开红色的N看了，但是看不了”
“哦，你那v2rayNG都没选择节点点击那个绿色飞机启动”
“哦哦，原来还要再点一下纸飞机哦”
你以为这样的女朋友很傻很少见么？我说说我老婆吧，我帮她也是安装好了v2rayNG和Netflix以及一个nplayer用来局域网看电视剧的
几乎相同的事情发生在我的身上了：
“老公你上次给我安装的看韩剧的东东是哪个啊？”
“你那个加速器打开了么？”
“打开了呀，视频app是哪个呢？”
“我不是只给你安装了一个视频app么，就是那个红色的N”
“哦哦，上几次都是另外一个彩色的n那个视频app，分不清了”
“嗯，其实那个叫播放器，不是视频app”
然而她已然抱着手机去看韩剧了，我的解释估计完全没兴趣听也记不住。
四、编的故事
小故事说完了，个中滋味每个人体会都有所不同
那么对于一个男人来说，尤其是划水娱乐脚本多年的男人，本以为vless就是个小儿科，结果长达30多个小时的折腾后，我只想说
又臭又长的千足虫json格式搭配v2ray/xray团队语焉不详，懂得都懂的玄幻文档和互相矛盾，互相过期，惜字如金的解释，堪比微软和甲骨文大厂大项目的文档参数解释
我感觉就像3岁的时候学字，这个是大，这个叫做小，这个是山，这个是水，好了现在你可以描绘出一幅美景了，大大的山里流淌着小小的水流，你认识到水能组成小溪，自然而然小溪越来越大就成了江河湖海，最后汇聚成一副美丽的画卷....
“vless草鸡吊，xtls黑科技，the next generation!”
“vless配置很简单的啦，你就这样，那样，就配置好了”
说真的，团队们做的那套一键脚本还真是淋漓尽致，颇有三大操作系统部署，全系统掌控的全面详尽水准了，说大佬们没努力没水平那是不可能的，但是对于想自己用上的人来说，看着那演示和参数解释怎么看怎么怪异迷茫。
fallback难理解吗？并不难，开发者以为用户很难接受nginx和vless互换角色？
并不是，用户疑惑的是，为何vmess不要做回落，vless一定要做防检测回落干嘛？
alpn又是啥？对于不学网络和前端，不认识tcp udp网络协议不懂应用层协议层什么4层7层的Netflix用户来说，这不亚于考研
一蹦蹦这么多新参数出来，那本来就如同鬼画桃符的json配置，对于很多新手来说，都是勉强熟悉看懂了它的身材长相，捧在手心怕化了，小心翼翼把大佬劈里啪啦分享的配置文件一字不漏塞进自己的config.json里面小心翼翼按下Esc输入冒号wq检查无误后，并且拼写几次错误systemctl restart v2ray，终于成功了，就如视珍宝地雪藏供奉好，甚至不惜重金买下瓦工48.79刀套餐，果断加入新的快照，输入详细的备注信息提醒自己快照的内容，然后呼出一口气终于可以享受了
结果新版v2ray,vless之类的推荐的配置要么一个encryption none丢某个大括号的大括号里面，要么一个decryption none丢某个位置，也不解释下为什么要它们，为什么又不能写在哪里,要么这边客户端可以填加密auto，服务端什么的alterID不用64了，可以只要填4了，又是客户端小于服务端数字就行，又变成服务端要改成0，又让人举棋不定到底是删掉还是改成0都行，又是新年大礼包一堆 closed pipe吓得一堆萌新不知所措
一个字，乱，两个字，混乱，三个字，真的乱，四个字，一片混乱
我真怀疑跟这些大佬一起上班的同事会不会疯，迭代规则，信息传递，项目进度，客户推送真的是屎山叠屎山，史无前例，然后一堆萌新蹲在屎山边上看到一颗光头突然蹦出来，手中握着一枚金灿灿的屎色的金币，大呼，我找到了真理！
我本就是想体验下vmess换成vless少一层加密，好像还有个xtls更快更强，仅此而已，结果让我去学各种path，又增加什么dest xver还有alpn还有什么http/1.1,http2还有什么h2c和http2啥区别啊，http/1.1是不是只有http协议啊，nginx到底支不支持h2c啊，我现在访问自己的站点又是啥方式啊，怎么看啊，nginx又要with xxx module又要with xxx module还要xxx module然后才开始有资格体验受苦
一堆人说要默认留alpn 1.1啊，又有人说要alpn 2优先啊，放前面尽量让所有https fallback到http2啊（萌新瑟瑟发抖，是不是一个位置没放好就要被嗅探啊，好怕啊），又看到说各个回落path部分以最后的优先起效啊，为什么alpn 2优先怎么还放在最前面啊，啊不，什么是上面下面，什么是前面后面啊，我这只看到一条千足虫json眼睛花，哎哟喂这里多了个}，哎呀那里又多了个],卧槽decryption放进到clients框框里面了....大佬，大佬你怎么不说话了啊，救救我啊
一个星期过去了，饱受摧残的萌新打着饱嗝终于塞满了各种知识，接受了大佬们一通洗脑并且熟悉明白了这个vless能干各种事情，比如vless皮trojan馅的，vless皮咬开蹦出个vmess馅的，又比如咬开一个还能包着vmess还跳出来个ws的，还有trojan馅吃出来fallback回nginx的
大佬语重心长的说，vless的四种写法，你明白了嘛？
“明白了”
“好，让我考考你，请默写/vmesstcp /websocket /vmessws以及默认回落到trojan的四种写法”
萌新埋头刷刷刷奋笔疾书，大佬微微颔首
“大佬大佬，我这次终于满分了吧！”
“不，刚好及格而已，请问若你用 Nginx/Caddy 等反代 WS，acceptProxyProtocol值应该为true或false？”
“ture ?吧？”萌新A试探着回答
“大佬，什么是反代啊？”萌新B好奇宝宝问。
大佬我行我素，继续提问“支持"cipherSuites"的最小版本是1.2还是1.3？”“v2ray 版本不小于 v4.几才完美支持 trojan 协议?”
萌新们垂头丧气....
半个月过去了
“喂，你修的啥？”萌新A问身旁
“哦，我就老老实实学好vmess+tls +ws，回家好好种田就行了，你呢？”萌新B回问
“我在攻克cf cdn教材了，有希望进修三本，加油了”萌新A握了握拳。
“切，一群书呆子，把后端vmess换成vless，学习效率加倍，很简单的捷径都学不会”一位伪学霸路过嘲讽
“我已经开始经脉倒转，马上要参透vmess小周天倒转成vless大周天了哈哈哈”一位结丹期小能开始狂笑
“弱者，本座vless+tls+tcp已经略有心得了，秒你只需要一招”元婴期大佬蔑视
“哈哈哈哈，老子Xtls终成正果了！”渡劫期强者霸气四射
“咦，我好像学会了Vless +Xtls+ws+tcp?”一位披头散发的大佬从洞窟闭关出界
“什么嘛，我才筑基的都知道长老说的xtls不能和ws一起存在”一位新学子撇撇嘴
“大哥哥这是为什么呀，xtls不是说万能的嘛？”一位无灵根小姑娘咬着棒棒糖路过随口问道
“哎呀，我哪知道那么多，什么xtls不能ws搭配，因为啥谁前谁后功法不同，和nginx功法功能不同，有的能加cdn有的不能外套cdn，哎呀老复杂了”
“对啊，为什么啊，我就说感觉经脉不通，等等，那我刚才学会的是幻觉，不对，我怎么身体变轻了，我的肉身已经不见了？不。。。”那位披头散发大佬刚南柯一梦出关被点醒就化成了灰烬。
一位戴着眼镜的师姐路过，
“咦，是陆师姐，你怎么弃武从文了？”一群追捧者扼腕叹息，百思不得其解
“哦，我只是发现世俗界的牛津大学好像比这个学起来简单多了，顺手考个证，这不加深点理论理解，过来再研究修仙，不碍事”
五、篇落
vless配置参考和简单解释
安装脚本使用了xray的：
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
Vless前置+tcp+xtls回落nginx是比较不错的性能之选，简单贴出此配置如下
[collapse status="false" title="Vless+tcp+xtls配置示例"]
{
"log": {
"loglevel": "warning",
"error": "/var/log/xray/error.log",
"access": "/var/log/xray/access.log"
},
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "d7bfb96f-xxxx-yyyy-zzzz-b4520bc1b5c8",
"flow": "xtls-rprx-direct",
"email": "a@omo.moe"
}
],
"decryption": "none",
"fallbacks": [
{
"alpn": "h2",
"dest": "/dev/shm/h2c.sock",
"xver": 0
},
{
"dest": "/dev/shm/h1.sock",
"xver": 0
}
]
},
"streamSettings": {
"network": "tcp",
"security": "xtls",
"xtlsSettings": {
"alpn":[
"h2",
"http/1.1"
],
"minVersion": "1.2",
"cipherSuites": "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"certificates": [
{
"ocspStapling": 3600,
"certificateFile": "/usr/local/cert/omo_moe.crt",
"keyFile": "/usr/local/cert/omo_moe.key"
}
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
}
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"protocol": [
"bittorrent"
],
"outboundTag": "blocked"
}
]
},
"outbounds": [
{
"protocol": "freedom",
"settings": {}
},
{
"tag": "blocked",
"protocol": "blackhole",
"settings": {}
}
]
}
[/collapse]
示例的是unix进程方式对接nginx，另一种fallback方式是端口方式，对于http2协议和http/1.1，因为后端nginx监听不能在同一个端口监听两种协议，所以只能分开
nginx这边对接配置如下：
server
{
listen 80;
server_name www.us.omo.moe us.omo.moe;
return 301 https://us.omo.moe$request_uri;
# access_log /var/log/nginx/omo.moe.access.log main;
}
server
{
listen unix:/dev/shm/h1.sock;
listen unix:/dev/shm/h2c.sock http2;
server_name default_server;
# return 301 https://us.omo.moe$request_uri;
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; #启用HSTS
root /home/wwwroot/omo.moe;
index index.html index.htm index.php;
#charset koi8-r;
access_log /var/log/nginx/omo.moe.access.log main;
# return 301 https://us.omo.moe$request_uri;
ssl_certificate "/usr/local/cert/omo_moe.crt";
ssl_certificate_key "/usr/local/cert/omo_moe.key";
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_prefer_server_ciphers on;
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
需要注意的是，80端口www/不带www的在vless作为分发得到的http2和http/1.1流量数据不能直接301跳转到同一个https://域名，我不会，我学的都快走火入魔了，已经放弃了，好像大佬与萌新都不在乎这点小细节
第二个server段内，带www的https也无法跳转到不带www的https，我就注释掉了，否则无限循环重定向
所以目前研究的进展只能做到手动输入http:域名的跳到https,和直接https访问，而带www的http会跳转到带www的https从而报错，并且直接访问www的https也是报错
我真的不想为了vless那点性能提升去学习透彻毛子的nginx庞大的参数了
这是老夫学会的一式半招，在此分享留给有缘人希望能帮你参透一二吧
对了， location ~ .php
这些php区域里面记得填上
fastcgi_param HTTPS "on";
因为从vless接手过来的数据就是纯粹的无加密tcp数据了，你只能强制让nginx服务器转变成https数据再out发送出去。
没加密的tcp数据是什么样子的？那是剑意，只能意会，不可言传，自己悟去吧
最后我知道你想问的，vless真的安全嘛？
我只想说，我不懂，我觉得像皇帝的新衣，它很凉快，很轻便很强大，但是确实是穿着衣服的呢。
哦，忘说了, r6400用vless+xtls能跑到60mbps了，确实还不错。
如果无法忍受https://www 不能跳转的小问题，那么折中方案就是vless+ws+tls ，nginx前置依旧，只简单修改vmess配置为vless的即可，参考示例：
[collapse status="false" title="nginx+ws+tls+vless"]
{
"log": {
"access": "/var/log/v2ray/access.log",
"error": "/var/log/v2ray/error.log",
"loglevel": "debug"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 12345,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "your UUID"
}
],
"decryption": "none"
},
"sniffing": {
"destOverride": [
"http",
"tls"
],
"enabled": true
},
"streamSettings": {
"network": "ws",
"security": "auto",
"wsSettings": {
"headers": {},
"path": "/yourpath"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": {}
}
]
}
[/collapse]
附 中转配置
中转的话，貌似vless无法直接中转？所以outbound这里沿用vmess或者你喜欢的其他trojan或者什么的协议应该也可以达到效果。落地机依然保持原来的vmess或者对应接收协议不变就行，建议配置完毕后清除所有#，//注释内容。
当然你也可以将中转鸡完全做成流量转发配置，也就是iptables，firewalld，gost纯转发流量。
另外作为落地机只是解锁流媒体典型场景，还可以在中转鸡添加routing区块配置只转发Netflix流量到落地机，实现私家车合租落地节点，减少滥用的效果。
"routing": {
"rules": [
{
"outboundTag": "blocked",
"protocol": [
"bittorrent"
],
"type": "field"
},
{
"type": "field",
"outboundTag": "HKT",
"domain": ["geosite:netflix"] // netflix流量走 落地机
}
]
}
[collapse status="false" title="vless中转鸡配置示例"]
{
"stats": { },
"log": {
"loglevel": "warning",
"access": "/var/log/v2ray/access.log",
"error": "/var/log/v2ray/error.log"
},
"api": {
"tag": "api",
"services": [
"StatsService"
]
},
"policy": {
"levels": {
"0": {
"statsUserUplink": true,
"statsUserDownlink": true
}
},
"system": {
"statsInboundUplink": true,
"statsInboundDownlink": true
}
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 12345,
"protocol": "vless",
"settings": {
"clients": [
{
"email": "a@omo.moe",
"id": "UUID_1",
"level": 0
},
{
"email": "b@omo.moe",
"id": "UUID_2",
"level": 0
},
{
"email": "c@omo.moe",
"id": "UUID_3",
"level": 0
}
],
"decryption": "none"
},
"sniffing": {
"destOverride": [
"http",
"tls"
],
"enabled": true
},
"streamSettings": {
"network": "ws",
"security": "auto",
"wsSettings": {
"headers": {},
"path": "/yourpath"
}
}
},
{
"listen": "127.0.0.1",
"port": 8080,
"protocol": "dokodemo-door",
"settings": {
"address": "127.0.0.1"
},
"tag": "api"
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": { },
"tag": "direct"
},
{
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "hkt.omo.moe",
"port": 23333, #落地机nat nginx对应的外部端口是23333，所以中转鸡outbound转发到落地机的监听端口是23333.
"users": [
{
"email": "b@omo.moe",
"alterId": 0,
"id": "UUID_2",
"level": 0,
"security": "auto"
}
]
}
]
},
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"allowInsecure": false,
"serverName": "hkt.omo.moe"
},
"wsSettings": {
# "certificates": [ #这里一路都是我自己域名转发，不确定如果你的落地机使用别的域名或者证书是否需要添加对应落地机的证书配置，放着供参考
# {
# "certificateFile": "/usr/local/cert/omo_moe.crt",
# "keyFile": "/usr/local/cert/omo_moe.key"
# }
# ],
"headers": {
"Host":"hkt.omo.moe"
},
"path": "/yourpath"
}
},
"tag": "hkt"
},
{
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "2.2.2.2",
"method": "aes-256-gcm",
"password": "mypassword",
"port": 1997,
"ota": false
}
]
},
"tag": "ss"
}
],
"routing": {
"strategy": "rules",
"settings": {
"domainStrategy": "IPOnDemand",
"rules": [
{
"type": "field",
"outboundTag": "direct",
"domain": [
"geosite:cn"
]
},
{
"type": "field",
"outboundTag": "direct",
"ip": [
"geoip:cn",
"geoip:private"
]
},
{
"type": "field",
"user": [
"b@omo.moe"
],
"outboundTag": "hkt"
},
{
"type": "field",
"domain": [
"xx.xx"
],
"outboundTag": "ss"
},
{
"inboundTag": [
"api"
],
"outboundTag": "api",
"type": "field"
}
]
}
}
}
而我们落地机依然保持不变，演示如下：
{
"stats": { },
"log": {
"loglevel": "warning",
"access": "/var/log/v2ray/access.log",
"error": "/var/log/v2ray/error.log"
},
"api": {
"tag": "api",
"services": [
"StatsService"
]
},
"policy": {
"levels": {
"0": {
"statsUserUplink": true,
"statsUserDownlink": true
}
},
"system": {
"statsInboundUplink": true,
"statsInboundDownlink": true
}
},
"inbounds": [
{
"port": 12345,
"protocol": "vmess",
"settings": {
"clients": [
{
"email": "a@omo.moe",
"id": "UUID_1",
"level": 0,
"alterId": 0
},
{
"email": "b@omo.moe", #这里对接的是中转机UUID_2，从nat外部端口23333映射到内网443端口，nginx监听443后反代配置传到vps内部12345本地端口。
"id": "UUID_2",
"level": 0,
"alterId": 0
},
{
"email": "c@omo.moe",
"id": "UUID_3",
"level": 0,
"alterId": 0
}
]
},
"streamSettings": {
"network": "ws",
"wsSettings": {
"path": "/yourpath"
}
}
},
{
"listen": "127.0.0.1",
"port": 8080,
"protocol": "dokodemo-door",
"settings": {
"address": "127.0.0.1"
},
"tag": "api"
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": { }
}
],
"routing": {
"settings": {
"rules": [
{
"inboundTag": [
"api"
],
"outboundTag": "api",
"type": "field"
}
]
},
"strategy": "rules"
}
}
//使用/usr/bin/v2ray/v2ctl api --server=127.0.0.1:8080 StatsService.QueryStats 'pattern: "" reset: false'查询>流量数据
///usr/bin/v2ray/v2ctl api --server=127.0.0.1:8080 StatsService.GetStats 'name: "user>>>a@omo.moe>>>traffic>>>uplink" reset: false'查询指定用户流量
[/collapse]
六、后记：
执着于和墙作斗争的精神，诞生了这些无私奉献的大佬，我从他们的工作节奏，开发点滴能感觉的到那种对抗甚至带着一丝疯癫，为了证明自己还是为了炫耀，其实都是一念之间。
其实我并不看好xray甚至整个v2ray的前景，大佬们可敬，但是走向的路确是可悲的，历史的车轮滚滚向前，哪怕你一只蚂蚁做出来钢筋小屋，也只会被车轮压进泥土，成为最坚固的牺牲品
国内反诈app战略部署于miui13，各种银行卡断卡行动，手机卡局停，地域性不发货，本人来当地营业厅实名解封，越来越多的摄像头和大数据收集，越来越快的舆论公关清理效率，我们注定只会成为可悲的蚂蚁，有的蚂蚁嘲笑着独行的瓢虫居无定所，随时被飞鸟叼走的动荡生活，自己捧着按劳分配的那些食物躲在蚁穴安然自得，有的蚂蚁羡慕外面的自由和挑战，当然，有的瓢虫也会羡慕蚂蚁的安定和谐。
可是蚂蚁终究是蚂蚁，即便长了翅膀，飞出去，也无法融入瓢虫，瓢虫再好奇蚂蚁的生活，也只是暂居，终究心向蓝天，随时会离开。
我是一只蚂蚁，我在嘲笑那些奋斗在一线和车轮斗争的工蚁们，等着他们力竭，等着他们被撕成碎片，化为养料加固这钢筋牢笼
我是好人？因为我也在冒死分享，只是和他们岗位不同？
我是坏人？因为我在嘲讽前行者，冷眼旁观？
我不知道，其实我们都不是人啦
这世道，有几个人有资格是人？
都是蚂蚁
都会化成风
只不过每只蚂蚁确实都羡慕会飞的瓢虫
有的真的长出翅膀，飞向远方
有的只能在心中长出翅膀
想飞
因此我们在此相遇
We To Fly
新的一年，大家继续前行，或许你就能翻出来屎山里面属于自己的那枚金币
