前身是大二时历时一月开发的程序，几经风霜，经过了几年的时间不断的优化和更新迭代，时至今日，还在不断的维护当中，不忘初心。

分情破爱始乱弃，流落天涯思别离。

如花似玉负情意，影如白昼暗自迷。

随风浮沉千叶落，行色匆匆鬓已稀。

一首藏头，讲得清未来，却倒不回过去，执着只为你，愿你一切安好。

那些故事

摘自2013年11月9日赴北京时写的博客：

• 1、软件的由来:由于13年10月份去出游导致被滞留在了杭州，不喜欢一切按计划执行所以没提前买票，从那时候我才知道什么是抢票。
• 2、成功抢到票:某A抢票提示音+某B订票提前设定好的参数(其实那时候是放出了10多张票，并不是我手快(-_-||))。
• 3、软件的目的:当时其他软件满足不了自己的需求，某些软件功能很多，却并没有完全的自动化，以及一些其他的软件只能抢一个车的等等。
• 4、软件的进度:搭建基础框架>初步实现可以登录>初步修改可以订票>修复和添加其他功能>发布和更新(到今天刚好一个月的时间，也包括其中很多次放弃的时间)。
• 5、软件的流程:登录>输入出发地目的地日期等参数>查询预定>设定参数>开始抢票(其中很多可变性供大家研究)。
• 6、软件的发布:一开始就为了自己使用而做的，因为自己经常不在电脑旁，但至今为止没再用到过火车票(-_-||))，所以决定让身边的人用，所以你能看到证明我们很有缘分(*^_^)。
• 7、之后的任务:做了整整一个月了也累了，马上要去北京了可能没时间去做这个了，不过如果有问题我还是会来修复的。

2013年春运：新版12306，选择重生

• 1、12306新版上线，意味着之前写的一切都已失效，对于一款适配网站的软件，网站整体改变，软件就需要重新写。
• 2、默默的发布了停止更新的公告，毕竟在上面花费的精力太多了，不能一直这样下去。
• 3、每天都有人希望我复出，考虑了几天更多的是内心不甘吧，还是默默的开始了几天的不眠不休。
• 4、记得当时3天4夜没休息，至今想起来都不知道当时是怎么做到的，那些室友却见证了这一切，认真了就不困了。

2014年春运：接近于暴走的年代

• 1、12306宣布60天的订票期，然而事情却没有这么简单。
• 2、糟糕的是，分流的官网屡次崩溃，服务器转到了阿里云，然而攻击并不是主要来源，而是用户的爆增。
• 3、而这时候淘宝卖家也来捣乱，他们卖着免费的分流，价格却高达30元。
• 4、通宵达旦已是家常便饭，却还要忍受着各种压力和气愤，注定是难忘的一次回忆。

2015年3月：更换图形验证码

• 1、12306出其不意的使用图形验证码，引起各方媒体和学者一阵动荡。
• 2、收集题库成为了新的出路，离开了电脑识别，云识别显然难度颇大，技术与服务器要求更高。
• 3、20日首位发现可以绕过验证码的漏洞，并发布了自动识别的版本，微博为证。
• 4、3天后其他软件相互盗用，在1天内被12306知晓并修复。气有什么用？有的作者甚至说：早就知道只是不发布而已。我只想呵呵。
• 5、争吵过后我把重要的功能封存在了服务器，由负载均衡调用内网服务器，保证技术的安全，并不是我没有分享精神，只是不想悲剧重演。

2015年7月：电脑识别重生

• 1、实际上不是电脑识别，应该叫云识别，只是还算不上云，只是交由服务器去处理了。
• 2、实际上5月已开放，只是单单开放了登陆部分，考虑到技术的成熟和不确定的因素。
• 3、最初针对全部用户开放，然而加密算法却被反编译，毕竟行行有专攻，.Net语言的安全性确实只有企业加密(价格昂贵)才能保证。
• 4、同样的请求，分辨不出是否为自身软件发起，然而却被用在其他软件批量登陆等功能上，自己的服务器跑着钱却帮别人服务。
• 5、故：暂时决定只允许赞助会员使用，由服务器二次验证，等一切趋于稳定，加密的事宜将着重考虑。

2015年12月：581种类目+双词验证码

• 1、[第一回合]为了阻挡机器学习的验证码识别，12306陆续加入了581种验证码类目
• 2、分流云识别在1天的时间完成了自主学习，在业内率先宣布告破。
• 3、[第二回合]然而第三天12306订单验证码则采用双词组合形式，这一个双词直接将结果集拉升到次方级别。
• 4、连夜修改了云识别的各种算法，精确适配12306种种变动，双词的识别率10%一度提升到80%。在业内率先宣布告破。
• 5、[第三回合]然而12306又采用每天变更一批验证码来延缓学习，动态添加种类的小图进行组合，保证每个答案有新的、机器不认识的验证码。
• 6、云识别进入了白天识别率略低，夜间优秀的窘境，尽管如此也达到了最佳的效果。
• 7、[第四回合]没过几日12306又增加了4秒限制，验证码必须4秒后提交，否则认为是错的，不惜影响那些眼疾手快的人。
• 8、为了用户最快的提交订单，云识别登陆验证码仍提供识别，订单验证码的识别暂时关闭，未完待续。

2016年5月：云识别新接口接入

• 1、年后在做其他项目的时候，突然有了一些想法，顺着思路做了新的云识别分支。
• 2、新的深度学习，新的神经网络算法，新的处理流程以及自主学习，慢慢接入了。
• 3、在不断优化后，验证码的识别率逐渐提升，速度更在几十毫秒，甚至几毫秒。
• 4、不过毕竟不是春运，不知道12306是否还要更变态。不过，人在塔在，欢迎来到德莱联盟。

2017年1月：相对安静的12306

• 1、回想之前，12306对待第三方软件的态度，一直是想从技术上做限制，几经风波，12306似乎安静了许多。
• 2、然而对抗黄牛，12306始终没有停下来。整点不规律放票，甚至判断是否为黄牛行为，12306一直在静悄悄的做限制。
• 3、至于六成车票无需验证码，可以理解为：需要抢的车票都需要验证码，一堆票直接买的不需要验证码。总结一句：然并卵。
• 4、而新版云识别表现比较稳定，在12306三番五次升级图库后，依然可以在数小时内完成自主学习，而后期将会不停的继续优化。
• 5、不知道今后12306会不会憋什么大招，如果只是针对黄牛来限制，无论对普通用户，还是自身平台，无疑是一个有利无弊的方式。

2017年9月：12306上线帆布指纹

• 1、在十一抢票期间，12306加入了一个JS文件，获取浏览器的UA、分辨率、色彩位数、平台种类等，生成一个理论上可以区分每台机器的设备ID
• 2、其实在很早之前，12306就已经进入测试和调整了，正式上线时，其复杂的程度可见一斑，并且动态的更换算法，为了避免伪造，甚至一天多次更换
• 3、12306判断，当不携带这个设备ID频繁的请求查票时，将会被拒绝服务，当携带的设备ID频繁的请求时，也会被302重定向，甚至各种奇奇怪怪的事情发生
• 4、对分流而言，本身是为个人抢票的软件，面对这次帆布指纹，可以从几个技术途经实现，然而追求完美和不落下一个小伙伴的心态，确实费了不少的精力
• 5、而这时12306新的登录系统也并没有很完善，出现的问题都需要自己去找合适的解决方案，而这时的12306也在不断的调整当中，也需要不停的适配和跟随调整
• 6、这十多天一直在高强度的开发和思考当中，为了更完善而更新频繁，即使有推送配置的方式，很多时候必须要更新主体，经常被吐槽为刷版本狂魔，- –
• 7、个人愚见，帆布指纹并不能作为一个主要的是识别手段，全国这么多台机器，唯一性无法保证，有的用户IE浏览器打开12306就卡死，兼容性也并不完美

2018年1月：越来越人性化的12306

• 1、微信支付、订餐、选座、积分、新版的APP、证书等，尤其是新版APP，十分流畅，而用的框架很像蚂蚁金融的，可能阿里团队参与了开发
• 2、然而预售的放票量却少了，似乎为了避免黄牛，继续沿用分段放票，捡漏就越来越重要了。当然还有区间限售，因此买全程票的人也有很多
• 3、12306一直在做风控系统，对外也宣传达到了预期的效果，不过对于分流而言，并没有多少影响，只是不建议在公司刷票，共用IP容易被误封
• 4、12306要对付的黄牛，其实根本不缺拨号的环境，如果把IP作为计算条件，容易把正常的用户屏蔽，相信以后的风控可以真正的人性化

2019年1月：12306试点候补购票

• 1、12306封锁IP越来越严重，在公司抢票的用户，由于是一个外网环境，不免受到了误伤。还有由于运营商的原因都在一个IP下的用户也受到了影响。
• 2、即使因为这件事上了热搜，也并没有让12306改变这一策略，反而转向对IDC机房（云服务器）IP的限制，好像是针对那些抢票APP的云抢票功能。
• 3、今年试点了川渝方向的候补购票，如果抢到了候补，出票率挺高，如果没抢到，可能连抢的机会都没有。如果以后全面铺开，可能抢票会成抢候补了。
• 4、个人建议，12306可以做账号异常登录时手机核验登录、退票等敏感操作需要手机核验等功能。或许也可以避免黄牛冒用、注册后随便用的情况。

2019年4月：分流更换域名以及别名

• 1、分流抢票的英文别名：12306Bypass，为了简化名称，避免歧义，更改了别名，已更名为：Bypass，两个名称均代表分流抢票，中文名称保持不变。
• 2、之前的域名302跳转到了新域名：www.bypass.cn。分流软件也发布了更新版本，文件夹名称可能还是之前的，程序名称已自动更改为Bypass.exe。

2020年1月：全面候补和阿里滑块

• 1、候补已经准备了超一年的时间，可以相信其技术的成熟，以及全面封闭的安全性，但正是这种封闭，加上突然隐藏候补的排名，也不可避免带来许多的疑问。
• 2、比如，候补的排名是怎样的？第一时间候补的是否最先得到票？全程票的候补会不会比区间的候补更具有优势？为什么候补没候补到，有人却抢到了票等等。
• 3、前几年春运每年都大范围扩张一次图库，所以春运期间的验证码是平时的上千倍的难度，这两年却越来也简单，加上种种迹象，一种山雨欲来风满楼的感觉。
• 4、果不其然，几天之后滑块验证码出现，其背后为阿里云的人机智能，是已经运行了好几年的成熟的滑块产品，之后就展开了整个抢票行业和阿里技术的切磋。
• 5、滑动的过程和轨迹并不主要，主要是对于浏览器特征的识别，阿里UA算法可以清晰的分析是不是真实的用户浏览器，基于大数据分析是不是人为，不断训练。
• 6、高峰期十多天出现诸多故事，很明显阿里站在上风，抢票行业受到了不同程度的影响，没人能在短时间内挑战阿里多年积累，何况还是国内第一梯队的公司。

2021年1月：受疫情影响，出行人数骤降

• 1、由于疫情反复，多地区鼓励就地过年，相比同年出行人数减少了一倍，因为出行人数的减少，相比往年抢票变得相对容易了很多。
• 2、然而热门车次的区间限售问题仍然存在，因为需要保证铁路运力资源利用最大化，所以优先保证始发到终点的长途旅客（全程）的购票。
• 3、铁路车票预售期也由之前的30天，变更到15天，方便疫情调控，免费退票的政策也由之前的15天，变更到8天，8天及以上的免收退票费。
• 4、由于出行人数的减少，今年相对比较安静，没有很大的改动，整个出行高峰都笼罩在疫情的情绪之下，回不回家过年成了讨论的热点。

2021年9月：登录验证码的变更

• 1、经历了多年的图形验证码，被替换为更方便的滑块验证码，为了兼容性和预备方案，12306也增加了短信验证码登录，其代表了一个时代的终结。
• 2、图形验证码在推出后逐渐被机器学习识别，为了抵抗机器学习，需要大量的新图片补充，这对12306来说也是一项费时费力的事请，治标不治本。
• 3、最近两年并没有大范围的增加新的验证码，而且逐步降低了难度，导致出现了一些开源的识别算法，在用户体验和阻挡机器之间很难做权衡。
• 4、滑块验证码作为新兴验证码形式，其安全性和误杀问题，都可以在其后台不断的调优，承载如此数量的用户，这对阿里来说也是一种双赢。
• 5、如果滑块验证码胜任了工作，以后可能越来越多的网站接入滑块验证码，验证码的时代发生了变更，或许可以说12306再次引领了潮流。
• 6、对于用户来说，看不到滑块的困难，感受不到有何不同，因为所有变动都可以在后端把控，这种随时可调风控等级的方式，只在高峰期升级难度。

2022年10月：后疫情时代

• 1、每逢节假日，疫情易反复，防控较严格，出行减少，车次和车票也会根据疫情情况动态调整，其他只有一些细节的变化。
• 2、支付时限已改为10分钟、单次购票可选9名乘客、单次候补最多支持5个不同的车次+席别组合、卧铺已支持批量改签。
• 3、部分用户遇到了账号买票被阻止、买任何票都要先排队等风控手段。如果只是针对黄牛，希望不要误杀普通用户。
• 4、不放票越来越普遍，第一时间抢到候补并支付(按支付时间排名)很重要，刷票也很多人抢到，建议候补+刷票同时进行。

2023年9月：验证码的再次变更

• 1、不知道什么缘故，滑块验证码被撤下，只剩下短信验证码以及早就有的扫描二维码才能登录，两者都必须拿出手机。
• 2、有些用户验证码下发了一直没收到，可能手机或运营商问题，也可能根本不是手里的手机号，实在不行就用扫码登录。
• 3、虽然这样牺牲了用户的方便，但会给12306APP进行引流，也给验证码时代画上了一个句号，理论来说增加了账号安全性。
• 4、为什么说理论呢，据说手机端有漏洞，不知道是持续爆破短信验证码，还是绕过了人脸，需要等待不固定时间就能登录上。