拿到微信 h5 页面的 token ，chrome 控制台拿到请求参数，postman 模拟了几个不用抢的专家号通过了。。然后写了个循环 100ms 请求一次 7 点放号的专家号，之前一直返回 7 点开抢。然后 7 点直接请求卡了 2 秒返回没号了。。感觉要不是别人也是脚本，要不就是后台有手脚。。

你都能用脚本，别人也能用呀

感觉你要并发执行才能提高成功率吧

别人写的 10ms

这个应该说明有同行

1 、先确定服务器与标准北京时间时差，不是所有服务器时间都是准的。2 、在快到点的时候，每 20ms 开一个线程去发送请求，总共发两三十个请求。直接发，不要关心是否有返回数据，千万不要等上一个请求响应之后再发下一个。

厉害的都走协议抢的，你这个太慢了

你的对手有可能是一家百人技术团队的大公司

我主要怕把他搞跨了，毕竟 token 有用户信息，参数也有朋友的身份证号...明天七点用多线程不等返回来试试..

专业抢票的不会有这么多顾虑

还是太礼貌了，嘻嘻。

脚本放出来学习下，看看怎么玩的

抢购其实没程序员想的那么简单,很多时候是经验问题而不是纯粹的技术问题以前帮人抢购场馆,同一 token 下将并发控制到了极限-刚好不被拦截的地步,为了尽量低延迟将程序部署到腾讯云同机房同网段遍历到了内网地址直接发请求,记得当时单请求响应已经到了 2-5 毫秒级别,我以为稳了,结果还是抢不赢别人后面复盘,怀疑对方已经将请求优化到了微秒级别,简单来说,假设平台放号是 1700000000.000000 这个时间点, 竞争对手有可能在选择 1699999999.999594 这个时间点发出请求,到达服务器的时候就能刚好抢到一张,而我的请求.000000 才开始发出,已经严重落后了,后面我又进行了小范围的提前请求,也没有成功,这种情况的话就需要长期的测试积累了,通过估算精确到一个极致才能保证领先,因为嫌麻烦就放弃了当然还有个可能平台直接内定了,这种情况更加不是技术能搞定的..

某国内知名大厂的某部门, 大概 5 年前是近 2000 部手机在爬某个公共事业部门网站, 抢某资源.一堆高级技术人员在维护这套系统...

正常 给孩子挂号 连挂上几天都试一个套路不让支付 哈哈 研究技术都多余

别怕搞垮，你找黄牛他们请求发的更狠。开挂之前跟朋友沟通好就行。你不要收你朋友钱，不要盈利，就不是黄牛，不会有大问题的。找到你的时候礼貌性道个歉，再打打感情牌，诉诉苦，疾病困扰，彻夜难眠，求医无门，才选此下策。

再写一个脚本，一分钟查询一次剩余号源数据，捡漏那些退号的，尤其是次日就诊的。

对了，如果有幸抢到，让你朋友千万不要对外说，更加千万不要给你揽活。病友追问就说找黄牛的，病友要黄牛联系方式，就说黄牛进去了或者洗手不干了。

对于你的这个目标，没有什么风控措施的，最理想的方案就是用上你最大的资源，短间隔高并发请求。对于有风控和频率控制的目标，那就是个技术活了。

这个时间差有什么好办法精确获取吗

我每天抢别的，刚开始三十多毫秒都没抢到，就知道也有人抢，后来调整定时任务执行时间在-30 毫秒范围就开始发起任务，定时任务开始执行-->我的应用系统-->再发起请求，我看过日志都有小几毫秒时差，后来就开了 3 个线程+异步，成功率高了很多。还写了监控每十分钟扫一次我监控中添加的列表。需求都是类似的。请求对方服务器也可能也有时差，所以综合就是前后几十毫秒多线程多次调用，再周期监控是否有放弃的名额。

我之前做了一个抢牛奶的，思路是手动用 tcp 发包，最后一个字符先不发，快到时间再发，你可以参考一下。

👍🏻

再刷一会，有时候 7 点零几才放号

这个发包具体是怎样的呀

tql, 这都能想到

棋差一招🤣

哪天人少去医院找大夫给加号大夫有可能会给加。可能需要早点去，去晚了加号的人多了可能就不给加了。抢号的很多的话有时候实际去看病的可能不多。某次我好像是星期天陪我妈去医院的时候人比较少。不过这种信息可能需要本人去医院确认或询问，如果是外地的话可能很麻烦。另外加号不知道是不是都需要去窗口加，反正我妈加的号需要在窗口人工挂号。我妈是之前在那个大夫那里看过，然后过了几天检查之后又去的，给加了。不过我妈找大夫加号的时候还有另外一个老头找大夫加号大夫也给加了。

好思路 下次我也试试

现在的抢号不一定行，因为服务器的算法都改成了开放时间的最先几秒提交的所有人都先放到池里，然后再随机选取了，而不是先到先得。

要先决定对方服务器的大概地理位置，比较远的话几十毫秒的延迟也是有的

uu ，这些东西有木有学习资料啥的，有时候挂个普通的号都很难抢

自己做得系统:我一般都是差不多到了.上服务器上改改时间..调快 3 秒..自己脚本再抢..别人的.脚本丢服务器: 到点"提前 3 秒"并发请求丢过去.不用管返回.但凡严谨些的.也很难写脚本抢购..它的原理需要你话几次的机会来琢磨..遇上专家是 2 个星期一次的号.那就坑了..有些参数是专家特定的 token.id 和时间规则等

＃16 这种这么抢手的，不会有人退的

＃15 一切看实际结果，你要是把系统搞崩了，导致医院无法正常就诊，你打什么牌都没用

100ms 你还写脚本啊。。。 都结束啦。。

＃22 好骚的思路

＃24 手动构造一下 http 的协议包就好了

把服务器搬到医院服务器附近

看品论有不少骚操作，学习了

＃12 腾讯云，可以遍历出别人的内网地址？ 这个应该不允许吧。 两个腾讯云用户在同一个机房，内网应该也是不通的才对啊

抢专家号别玩崩了把自己弄进去了

首先看两秒卡在什么地方。如果是卡在 tcp 拥堵，提前建立 tcp 链接，防止到时候申请不到。如果是系统后台卡，那就看运气了。你需要打个提前量。但是它系统做的烂，有时候无解。另外你 100ms 恐怕太乐观了。不要太小看手工抢票。哪怕别人不用脚本，纯手点，人数上来加手速快的多点，你都不一定能抢过人家。

对这里其实有一点吹牛，只是找到了对方的对应区而已然后部署到同一个区，估计只经过了一两个交换机转发，ping 值只有 0.x 毫秒 四舍五入约等于本网了

牛逼！“快到时间” 这个是手动还是自动，有文章分享没？

几年前搞过一个抢号的东西，卡着时间开了一堆 Docker ，每周一次，好几周都抢不到。一天做测试的时候，阴差阳错，在放票之前，直接发个 post 过去，哦豁，出票了...

我最后还是找的黄牛

没有意义的做法。首先 tcp 是流式协议没有包的概念，应用层必然是需要完整的 http 请求数据才能开始处理，不会因为某部分数据先到达就能比其他请求先处理。人为将一个请求在 tcp 层分割开发送可能造成，1.前一部分发得过早，在服务器端读取 http 请求超时，整个 tcp 链接 reset 废了，2.本来一个 http 请求数据不大时一个 MTU 包就能完整包含，拆分后丢包重传几率 x2 翻倍

换行符？😂

＃47 你也说到了, tcp 是流式协议。完整的 http 如果还没发送完呢? 对比参考一下文件上传就明白了

有没有可能 nginx 做了限流，1 分钟之内的请求都直接被转发了，甭管间隔多短怎么并发

什么叫走协议抢的，能解释下吗

这个帖子骚操作不少，我找过一个人抢矿机，结果钱付了，毛都没有，因为他说忘记部署了，这。。。我竟无言以对。

＃21 能留个联系方式吗？要是有东西做可以找你试试？

＃53 可以啊, emh1YW5ncGl3YW5n

＃47 他这个思路是先在抢票时间快到之前，把大部分数据发到对方服务器，留一个字节不发，这时候服务器就会因为 http 包不完整而阻塞直到超时（这个超时时间有个几秒到几十秒钟），抢票时间一到，立马把最后一个字节发出去，因为只有一个字节速度远远大于发一个完整的 http 包，服务器收到了这最后一个字节交给应用层

卷起来，另测一下不同网络环境的网络延迟，看看目标服务器地址，运营商类型和地区

学到了，好骚的操作

水深火热的帖子

办张有健康权益的信用卡，可以试试让工作人员帮你预约，上半年就用的这种方式预约了一个专家号。

的方法我以前也在用的, 我的还复杂点需要证书啥的, 也是自己写 tcp 留最后一丢丢发有几个注意的点:1. 提前计算 消息来回 时间, 建议直接看 http 头的时间2. http 协议是链路复用的, nginx 好像默认是 50 次, 记得开多个 tcp3.我都是提前半分钟用炮灰号测试, 后面上大号, 小赚几个 W

天眼查？

遇到有验证码这些是不是要识别验证码了，不可以人工写码吧。我上次为了抢浙中的专家号，直接 dump 支付宝里面小程序，改改本地 node 直接发. 上海华山的有验证码就不好搞了。

＃19 时间差获取其实不是很麻烦的。依靠 Response Header 的 Date 字段来确定，但因为 Date 是秒级的，所以需要一些技巧。先找一个同服务器上几乎不耗时的路径。比如 /robots.txt /favicon.ico 这类很小的且响应很快的静态资源。每隔 20ms 左右发送一次请求，记录发出时间、网络耗时、Date 头。举例来说：本地发出时间 12:00:05.800 ，服务器响应 Date 是 12:00:05 秒本地发出时间 12:00:05.820 ，服务器响应 Date 是 12:00:06 秒不考虑网络耗时的情况下，意味着服务器时间是 800-820 之间，从 5 跳到了 6 ，所以服务器快了 190 毫秒左右。实际上上面这个时间含网络耗时的，要精确点的话，再结合网络耗时计算一下，大概就能算出服务器的时差了。

为什么现在不用了

手动 tcp 发包的方法也太扯淡了……没实践过就别瞎说。这种行为本质上和 Slowloris 攻击没区别，当服务器都是傻子呢。

所有不加行为验证码的抢购就是图一乐,成事在天🤣

除了上面提到的“确定服务器与标准北京时间时差”、“降低发送的延时”、“直接分析协议”，-----------------------你还应该增加账号数量，比如微信，那就弄几十个微信账号，几十个公网 IP ，一起开程序/脚本来抢，增加成功概率 :)干黄牛的活就得专业一点 :)

鉴于楼上说的手动 tcp 方案太扯淡了，本来想简单吐槽一句，结果没忍住还是把这个事情说清楚吧。我这么说是有理论和实践经验做支撑的，tcp 手动发包几乎没有统计学上的有效性。这类需求前些年几乎是外包市场仅次于网站开发的业务，钱多门槛低。我自己做得很少，基本上是给别人指导一下，不做的原因主要是业务容易擦边，再就是现在多数大平台的都从抢的逻辑变成抽签逻辑了。先解释一下为什么有人认为“手动发包”是个有意义的方案。因为按照一般的“抢”的逻辑，以某个时刻为分界线，在此时刻之后某个特定资源就生效了。在此时刻之前到达服务器的请求是无效的，你希望你的请求恰好在这个时刻之后到达服务器。那么我们有能力确定服务器的时间吗？绝大多数时间不能。（少数情况下可以通过触发服务器错误等等获得一个相对时间差，然后加上网络延迟做一个粗略估计。）即使能够确定服务器时间，实际应用里也没有太大意义。“上线”这个事情 99% 不是自动化的而是人为的。因此所有人的策略都做出调整了，用大量链接去覆盖资源上线的可能时段。只要保证资源上线之后有一部分请求以尽量低的延迟到达服务器即可。这个时候 tcp 手动发包好像就体现出优势了？提前建立好（大量）连接，然后看情况开始发数据。注意这里的潜台词是，网站卡的原因在于 tcp 连接数不够，而且新建立连接会多 1RTT 的延时。但是这个思路是不是有点眼熟？如果很多人都是这样做，或者某个人控制机器人程序这样做，在服务器看来，客户端只连接不发数据，这连接还不会主动关闭，那它是不是就是 DoS 攻击？（这一类攻击有个专门的名字叫 Slowloris ）这里设定个非常简单也非常普遍的模型，来看看这个做法有没有可行性。或者说“连接数不够”这个假设是不是真的符合现实。就非常普通的单服务器 nginx 做 ssl offloading 和反代，配置近似默认，upstream 大概是某种动态语言的服务端。网络请求在闲时 10 QPS 忙时 10000 QPS 这样。（意思就是，规模不大，用户量有限。服务器网络带宽不是瓶颈，nginx 也大概率不是瓶颈，瓶颈在后端应用，挂号服务基本上就是这个水平。）这里套不套应用层防火墙差别非常大。一旦套一层 cf 之类的服务，手动 tcp 发包就没意义了。因为 cf 之类的服务会缓存请求然后回源，不可能在这个层面预先抢占 tcp 连接。如果退一步讲，服务器裸跑。这个时候你通过手动 tcp 发包，那能够获得的时间窗口有多长？在 tcp 层面，理论上 keepalive 是无限长的。但是实际上以国内的网络环境来说，经过 NAT 之后中间设备的映射缓存大概就是 150 秒这个水平。实践里可以找公网服务器、代理来绕开这个限制。提这个限制的意思是，利用 keepalive 机制几乎不需要你在程序层面上做很大的改动。但是在 nginx 服务器层面上，时间窗口就小得多。这类服务器默认对慢速攻击有应对，tcp 连接建立后，headers/body 的默认容忍延迟基本在 60 秒。（但凡看过一点点所谓的优化经验，这个值应该不会超过 10 秒）那就又回到之前的问题上了，你本来打算预先抢占 tcp 连接，结果时间窗口太小，当所有人的策略都是提前覆盖可能的时段，你的连接会被淹没在海量连接里面。这里有个非常极端的情况，这个 tcp 手动发包，利用 tcp 的机制，强行把 headers 分成多个包发送，然后每个发送间隔卡在目标服务器的限制之内。（这里就不提这个程序的复杂性了，要么魔改底层网络库，要么纯手写然后一直处理到应用层协议）但问题是 nginx 这类服务器的反代，一样会先缓存请求，在收到完整请求之后，再转发给 upstream 服务器。也就是说，你抢占了本地到 nginx 的连接，而没有能力抢占 nginx 的 upstream 的连接。现在回到核心的问题上，服务器在高并发的时候变卡的核心原因是什么？核心是服务端应用要对特定资源加锁，业务逻辑在高并发的情况下只能等。由于一般网站的瓶颈都在后端应用服务器上，nginx 能承载的客户端连接数远大于 nginx 到 upstream 的连接数。当应用服务器不需要处理锁事务的时候，平均响应可以做到很低。但是一旦遇到加锁资源的时候，这个响应时间会成倍增加，理论 QPS 就大幅下降。而此时所有人会更加疯狂地反复刷新，这时候 nginx 到 upstream 的连接就会长期占满。所以体感上就是，网站先变卡，因为 nginx 在等 upstream 释放出新的连接。等 nginx 撑不住了才会 502 错误。而从客户端来说，没有任何手段能保证你优先获得到 upstream 的连接。所以说 tcp 手动发包这个事情……别挣扎了。

你这抢票还等返回的。。 太文明了，这玩意儿只有他那边存库就行了，你只管发请求，使劲的超发。

给你个思路，就是去那些约号 app 上找那些专家，他们都可以花钱私聊，然后把症状都给医生说了，巴拉巴拉一大堆，最后说您的号太难约了，我已经约了 xx 天了，您看方便加个号不，最后就是第二天去加个号

还有个楼上说了，一些银行的信用卡（白金及以上）权益都有帮忙约号陪诊权益，可以试试

是的 瓶颈肯定不是 tcp 连接，不魔改底层发包协议，手动发 tcp 包肯定会被淹没在海量的请求中，而且很有可能当 Dos 被干掉。抢购的逻辑在后台不搞鬼的情形下，确实更像是一堆脚本抽奖了。

直接进后台自己加不好吗

＃72 如果服务方不愿意改变抢模式，这个事情就会演变成脚本大战。脚本大战一旦有人不讲武德，大量暴力发请求，结果就会变成另一个意义上的抽签。最终所有人的最优策略就是加资源提高中签率，尽管大家都知道这么做边际收益很低，但不得不这么做。另一方面你可以看到提供这种服务的主要模式都变成了“代抢”，甚至承诺抢不到加倍退款。对于商家来说，投入达到某个阈值之后中签率是比较稳定的，成本也是稳定的，只要代抢客户足够多就能赚。因为他们可以保证总有账号可以抢到，但没法保证某个特定账号能抢到。

这操作虽然骚，但是我不相信，除非 show you code /doge

之前一直有同事说要搞抢茅台，却没成功

作为爬过的过来人来讲，你尽量提前 20 分钟。一般他们都是提前 10 分钟，很不准时的。而且有 goujie

让我想起来提前一天上高速的大聪明

这栋楼的佬们, 我想问问电商哪些整点下单的送大礼的业务是不是同一批人也有在干.

我是用 java 写的，有很多方式和语言都行

在好大夫直接找到这个医生。花钱聊天后让这个医生给你加号。或者直接闯进去让医生加（早点去，态度诚恳点）。一般医生也会加的。

你这说到点上了不可能不给你往外说别给自己找麻烦

我看了眼，提前一天上确实不收费

这甚至不一定是个技术问题，没准需要抢的专家号都被关系户早订干净了

uu ，一般这些从哪些学习的，我也想整一个试试但是无从下手

现在需要抢的 除了大厂的，到点准时卡死 刷新都刷不出来 都被脚本干烂了

不是, 不能说.. v2 里估计很多混这个大厂的, 不知道这玩意是否涉密...

反思一下是否是脚本不够努力（请自带娘娘腔音效）

看到 lz 突然想请教个题外相关话，以前没抢过高铁票，今年第一次定时定点买国庆高铁票，发现开售瞬间所有车次票全售空，是不是携程网之类的抢票服务干的？所以这种特殊时期的高铁票我不应该 12306App 购买，而应该也加入第三方预约抢票大军是吗？

我先不说别的。就光说你七点卡请求你就肯定是抢不到了，这玩意算上延迟，你必须要提前抢，一看就是没有经验。只能说还有上升空间吧。

OP 抢到了吗

有没有可能，他接口里就没有号，只在前端页面显示 专家号预约 过几秒后在显示 预约完 ~ 内部早已分化好了日程排期~

你都卡着时间了为什么还开一堆 docker ？现在离开 docker 就啥都不会做了吗？

应用层“不必须”是收到完整的请求才开始处理也可以流式处理的看他们程序咋写吧

＃89 有可能根本就没放票，12306 会先放全程票和热门站点的票，小站的票会在最后几天才放，12306 也是要追求利润最大化的