很多人以为交易环节出问题都是对方的原因。实际排查下来，卡在提交这一步的情况相当常见：物品已经放上去，结算时转圈，最后提示失败，东西退回来还要重新操作一遍。交易能不能顺利走完，除了规则本身，还跟提交那一下的网络状态有关，而这一点平时很少有人注意，因为它不出现在任何设置项里。交易类账号对代理IP的要求，和批量跑任务的账号不太一样。
为什么交易这一步更敏感
交易和寄售的动作有几个共同点：一次提交包含的信息多、服务端要做的校验多、失败之后往往要重新操作。这三点叠加起来，对网络稳定度的要求就比日常操作高。日常操作失败一次无所谓，重来就是；交易失败一次可能意味着一次机会没了，或者需要重新准备材料，代价大得多。
- 挂单
- 提交信息量大，中途断开要重新填
- 改价
- 操作窗口短，卡住容易错过时机
- 领取
- 涉及数量校验，多数失败不可回退
- 结算
- 一次提交全部信息，最怕中途超时
提交那一下，值得单独照顾。
这几类动作里，结算最敏感，因为它涉及的东西最多。结算的时候，客户端要一次性提交和校验完所有信息，中间任何一个环节超时都会整体失败，而且失败之后往往没有中间状态可以恢复。盯着结算这一段做优化，收益比优化日常操作要大，代理IP这边也值得为它多留一点余量，因为日常操作的失败成本本来就低。
怎么降低失败率
三个办法。第一个是错开时间，别在活动结束那几分钟集中提交，那时候服务端本身就忙。第二个是保证代理IP稳定，交易前后的几分钟里别让同一条代理IP上跑别的重任务。第三个是失败之后不要立刻重试，隔十几秒再试，连续重试容易一直失败，反而把时间都耗掉了。
交易类账号的日常安排也可以顺着这个思路调整。把交易相关的操作集中在一个时段完成，这个时段里不让这些账号跑别的重任务，线路的资源就留给交易。其他时间该跑什么跑什么，互不影响。这样分开之后，交易失败的次数会明显减少，排查也简单，因为变量变少了。
还有一个细节是账号数量。多个账号在同一时刻提交交易，即使各自线路不同，服务端那边也会同时收到一批请求。如果这批操作时间敏感，最好再错开一点，让提交的节奏分散几十秒。
交易环节的稳定，靠的是把提交那一下照顾好，反复重试解决不了根本问题。
与代理IP的关系：交易和寄售对提交那一下最敏感，给这类账号配一条不被别的任务挤占的线路，比加带宽更实在。