LTE/5G网络优化实战：速率低、MOS差、随机接入失败排查方法论

1. 整体思路：业务问题排查的三层定位法

1.1 先定“面”再定“点”：指标看板与现场数据怎么结合

干网优这行最怕的不是问题难，而是问题来了不知道从哪儿下手。速率低、MOS<3、随机接入失败这几类问题，表面上风马牛不相及，实际排查时内核是同一个套路：先看面、后看点、再定根因。

所谓“看面”，就是先把小区级、基站级的统计指标拉出来过一遍。RRC建立成功率、ERAB建立成功率、掉线率、切换成功率、上行/下行PRB利用率、用户数、CQI、MCS分布，这些指标在网管里全都有现成计数器，不用自己造轮子。重点看三件事：第一，问题是不是集中在某个小区或某几个小区；第二，问题发生的时间段有没有规律，比如早晚忙时；第三，问题指标和周边指标有没有联动，比如速率低的同时干扰指标是否抬升。

“看点”则是针对问题小区做DT/CQT测试，或者拉取MR数据、基站告警、干扰检测结果做联合分析。这里有个经验：现场测试的数据一定要结合后台统计一起看。比如你路测发现某路段RSRP在-110dBm以下，速率上不去，后台看该小区上行干扰又很高，那基本可以判断是弱覆盖叠加干扰，单靠后台或单靠路测都容易误判。

最后“定根因”，把无线环境、参数配置、传输资源、核心网状态、终端行为几个层面逐一排除，锁定问题归属。这个闭环我用了很多年，不管问题多复杂，只要按这个顺序捋，很少有漏掉的。

1.2 工具链与数据源：DT/CQT、MR、网管计数器的配合关系

排查业务问题，工具和数据源是根基。DT路测主要解决“无线环境到底怎么样”的问题，能直接看到RSRP、SINR、MCS、BLER、吞吐量、时延等关键空口指标；CQT定点测试适合复现特定点位的问题，比如某写字楼18层靠窗位置速率低，用CQT定点多轮测试能快速确认是偶发还是常态。

后台侧，MR测量报告用来还原全网覆盖和干扰分布，特别是没有条件路测的小区，MR是最廉价的覆盖评估手段。网管计数器则提供KPI层面的证据，比如随机接入成功率、RRC重建比例、PDCCH聚合级别分布等。这几类数据的关系是：网管告诉你“有没有问题”，MR和DT告诉你“问题出在哪儿”，参数核查和信令跟踪告诉你“为什么出问题”。

很多新手喜欢一上来就抓信令，我个人不建议这样——信令浩如烟海，没有前面几层过滤，直接看信令很容易迷失。正确姿势是：先用KPI圈定问题小区，再用MR/DT缩小问题区域，最后用信令跟踪定位具体流程失败点。

提示：实际工作中建议提前准备一份常用指标ID和计数器对照表，不同厂家网管命名差异较大，在排查现场临时查文档非常耽误时间。

1.3 排查方法论：从现象到根因的通用闭环

一个成熟的问题排查流程，应该是一个六步闭环：现象描述→数据采集→范围收敛→假设验证→根因确认→优化实施。

现象描述要具体，不能只说“速率低”，要说清楚“哪条路、哪个小区、哪个频段、什么时间段、下行还是上行、平均多少、峰值多少、什么业务”。数据采集要全面，空口、传输、核心网、终端四类数据尽量同时取。范围收敛就是前面说的“面→点”，把问题框到具体小区和具体地理区域。假设验证阶段，针对可能的根因做定向调整或测试，比如怀疑PRACH功率不足，就抬升preamble初始接收目标功率再观察指标。根因确认后，优化实施阶段要记录调整内容和预期生效指标，避免做“糊涂账”。

这套闭环的好处是：每走一步都有数据支撑，不会出现“调到哪算哪”的情况。我在团队里带新人，会强制要求他们按这个模板写排查报告，写不出来就说明没想清楚。如果你想把这套方法复制到自己的工作中，就直接把这个六步闭环当作排查前的检查清单用。

2. 速率低排查：先看无线，再看传输，最后查核心网

2.1 无线侧自查清单：RSRP、SINR、MCS、RB数逐项过

速率低是投诉量最大的一类问题，几乎每天都遇到。无线侧排查，我习惯按“覆盖→干扰→调度→能力”四层往下查。

第一层覆盖。把测试路段的RSRP和SINR拉出来看。如果RSRP低于-110dBm，说明弱覆盖，话不多说先解决覆盖问题：调天线下倾角、加站、加直放站或者调整功率。如果RSRP在-105dBm以上但SINR很低，比如低于5dB，那大概率是干扰问题，而不是覆盖问题，此时需要查上行干扰和模三干扰。很多新手看到吞吐量低就急着调MCS或加大带宽，结果发现没用，就是因为没分清弱覆盖和干扰的区别。

第二层干扰。LTE系统内干扰主要看PCI模三干扰、GPS失步导致的时隙干扰、异系统干扰。模三干扰从MR或路测数据里能看到SINR差但RSRP不差的特征；外部干扰则要看上行每个PRB的干扰噪声抬升，如果干扰底噪抬升到-100dBm以上，就要考虑扫频排查外部干扰源了。5G NR还要额外关注SSB波束配置是否合理、邻区PCI混淆类问题。

第三层调度。看调度率、RB占用率和MCS分布。如果RB占用率低，说明资源没用起来，可能是用户少但业务需求低，或存在调度问题；如果MCS长期在低阶比如QPSK/16QAM，说明信道质量差，需要回到前两层找原因；如果MCS高阶但吞吐量仍低，就要怀疑传输带宽或核心网侧。

第四层终端能力。查看终端是否支持高阶调制、是否支持4x4 MIMO、是否支持载波聚合、双连接。同一位置，支持256QAM和2x2 MIMO的终端，与只支持64QAM的终端，峰值速率差距可以到30%以上。这个因素在做单用户速率测试时影响尤其大。

注意：排查速率低时，一定要先确认测试终端和软件配置。真实场景里，终端锁频段、软件限速、服务器性能不足等非无线原因，会让无线侧优化白费功夫。

2.2 资源调度与参数核查：PDCCH聚合级别、CQI周期、DRX

无线环境没问题但速率还是上不去时，就要把目光投向调度和参数配置。

检查PDCCH聚合级别。LTE和NR的PDCCH都有聚合级别1/2/4/8，级别越高，控制信道占用资源越多，留给PDSCH和PUSCH的资源就越少，最终影响吞吐量。如果全小区大量用户聚合级别为8，说明PDCCH容量受限，可考虑优化公共信道功率分配或开启PDCCH自适应降级功能，但要注意降级不能激进，否则会导致PDCCH漏检率升高。

检查CQI上报周期。CQI是终端反馈给基站的信道质量指示，基站依据它来选MCS。如果CQI上报周期过长，信道变化快时基站用的MCS会保守，吞吐量就会被压低；如果上报周期过短，PUCCH开销增加。实际配置中，周期一般设置在5ms到20ms之间，需要根据信道变化速度和使用频段做平衡。5G里还要检查CSI-RS资源配置，CSI-RS端口数太少或周期配置过长，同样影响MCS选择。

检查DRX参数。DRX省电机制在手机亮屏下载场景下影响很明显。如果DRX的onDurationTimer调得太短，终端频繁进入睡眠，调度机会减少，吞吐量会周期性掉坑。排查时打开DRX关闭对比测试，能快速验证是不是DRX参数导致的问题。

检查双连接和载波聚合类参数。LTE的CA、5G的NR-DC都对峰值速率有决定性影响，要确认辅助小区的添加策略、门限和BWP配置是否正确。特别是5G NSA场景，如果SCG添加失败率高，数据一直走LTE锚点，5G速率不达预期就非常正常了。

2.3 传输侧与核心网不可忽视的瓶颈

空口全绿、调度正常但速率依旧上不去的项目我做过不止一个，最后查出来都是传输和核心网的问题。

先看传输链路带宽。很多站点的传输带宽看似是千兆，实际因为传输设备端口配置错误或运营商传输波分资源不足，实际可用带宽只有两三百兆。直接在基站侧ping核心网的服务器，用iPerf打流测速是最直观的验证方式。我遇到过一个现场：基站S1接口配置了1Gbps，传输核心交换机只给了300Mbps的qos模板，现场测试峰值速率卡在280Mbps死活上不去，解开传输模板后速率立刻翻倍。

再查核心网侧用户面路径。EPC/5GC的UPF或SGW/PGW是否为主控板转发瓶颈、用户面路径是否跨地市绕转、是否存在NAT或防火墙限速，这些都会造成“空中看着好好的、用户体感却很差”的现象。特别要注意共享基站场景，有时候小区接入了别家的核心网，流量绕了一大圈，时延和速率都会劣化。

最后看一眼传输误码和丢包。传输光模块劣化或光缆衰减增大，会导致物理层误码率抬高，重传增加，TCP吞吐量断崖下跌。排查时让传输专业查一下SDH/SPN链路的误码统计，不要被“光功率正常”这种结论迷惑，误码才是关键。

我在实际排查中，基本每一两周就会遇到一次“无线优化做了一大堆，最后发现是传输问题”的案例。经验就是：无线侧数据采集完成后，必须同步排查传输和核心网，至少要做一次端到端打流测试，把用户面各段的速率能力都拉出来验证一遍。否则优化的方向可能从一开始就跑偏了。

3. MOS值低于3：语音质量问题不只是编解码的锅

3.1 什么是MOS值：语音体验的“体检报告”

MOS(Mean Opinion Score)平均意见分，是衡量语音质量的最直观指标，取值范围1到5分：5分表示完全听不出失真，4分是高质量通话，3分以下就开始有明显失真、断续或杂音，终端用户体验已经比较差了。传统PSTN语音质量通常在4.0分以上，VoLTE/VoNR目标值一般定在3.8到4.2之间，如果实测MOS持续低于3，说明语音链路存在明显问题。

MOS的来源有两类：一类是主观测试，请真人听音打分，最准确但成本极高，日常很少用；另一类是客观评估，通过算法模型计算。VoLTE/VoNR场景常用POLQA算法，它基于语音信号损伤因素如编码损伤、丢包、时延、抖动来预测MOS值，路测软件里的MOS就是基于这种算法估算的。理解这个原理后就会明白：MOS不达标时，我们要解决的不是“怎么让打分提高”，而是“什么因素造成了语音损伤”。

3.2 影响MOS低于3的四个核心维度

四个维度分别是编码、时延、抖动和丢包，排查时要逐个验证。

编码层面的核心在编解码模式和是否发生编解码转换。VoLTE通常采用AMR-NB或AMR-WB（宽带自适应多速率），AMR-WB音质更好，MOS基础值也更高。如果通话过程中发生编解码转换，比如从AMR-WB降为AMR-NB，或者经过不支持宽带语音的旧设备导致转码，MOS会被拉低0.5到1分。这类问题查SIP信令里的SDP协商结果就能确认。

时延影响的是通话自然度和交互体验，端到端单向时延超过300ms就会出现明显的“对讲机”效应，即使MOS算法里时延权重不是最大的，用户感知依然很差。排查时延要看空口调度时延、传输时延和核心网处理时延，分段ping或抓包打时间戳可以定位时延瓶颈。

抖动是影响VoLTE语音MOS的关键因素。语音包到达时间忽早忽晚，接收端Jitter Buffer要吸收抖动，抖动太大时先增加的缓冲时延提高MOS，缓冲也扛不住，只能丢包，语音就断断续续。从基站侧看，要关注上行调度是否及时，特别是小区用户数较多时上行资源竞争对VoLTE包时延抖动的影响很大。

丢包最直接。1%的丢包对MOS影响还小，3%就明显下降，5%以上语音基本没法用。丢包原因可能是空口链路差（弱覆盖、干扰）、切换中断、RRC重建或者传输拥塞。排查时用路测软件的RTP丢包率、BLER和RRC重建次数联动分析，哪段链路丢包多，问题就在哪。

3.3 VoLTE/VoNR语音质量的参数核查与优化动作

语音质量的优化，参数层面的动作比改天线要频繁得多。

核查VoLTE的QCI配置。VoLTE默认为QCI1承载，5G VoNR则为QCI5默认承载加QCI1专用承载。如果QCI1承载的调度优先级配置不对，或者GBR带宽配置过小，忙时语音包会和数据业务抢资源，MOS被直接拉低。QCI1的保障速率一般建议配置为上下行各40到80kbps，但语音帧的实际码率加RoHC头压缩开启情况会变化，需要预留余量。

开启RoHC（鲁棒性头压缩）。RoHC能把RTP/UDP/IP头从40字节压缩到4字节左右，大幅节省空口资源降低时延和抖动。这是VoLTE提MOS最有效的参数优化之一，建议全网开启。5G VoNR里有PDCP-Duplication选项，对URLLC场景更有效，VoNR里要谨慎，因为它消耗双倍资源，通常只在丢包较高时对小范围用户开启。

核查切换参数。语音业务的切换失败和切换中断，直接表现为短暂掉话和严重丢包，进而导致MOS大跳水。重点核查A3事件的触发门限和迟滞、切换目标小区的T300/T304定时器、以及异系统切换门限（LTE到GSM/CDMA的盲重定向门限必须合理）。在VoLTE部署初期，很多MOS低的问题都是因为过早切到GSM或2G，回到3G/4G后MOS很难看。

控制Jitter Buffer参数。终端侧的Jitter Buffer分为Adaptive和Fixed两类，Adaptive模式能自动适应网络延迟变化，推荐使用。若参数配置过于激进，缓冲过小可降低时延但会增加丢包，过大会增大时延但缓冲更稳。实测中可以把Jitter Buffer从40ms调整到80ms对比MOS变化，往往能摸到最优值。但这需要终端配合，运营商侧能做的更多是保障网络层的时延、抖动和丢包达标。

3.4 现场复测与问题定位实拍记录

MOS问题最终要在路测和CQT里复现和验证。我调一个VoLTE MOS问题的典型流程是：先选一条确定的测试路线，固定测试终端（一般用同一款手机和测试软件），按早上、中午、傍晚三个时段各测三轮，取的MOS最低值和平均值作为基线；然后后台同时采集S1/Xn接口的跟踪数据，记录每一通电话的SIP信令、RTP流统计、切换事件和异常事件。

有一次处理某商圈MOS持续低于2.8的问题，路测发现所有问题通话都发生在同一条路面，切换带附近；后台信令显示切换时存在连续两次RRC重建立，每次重建立会造成300至500ms的语音中断，两三次累计下来MOS就掉到了2.5左右。根因是切换目标小区信号弱，源小区A3迟滞设得太小导致过早切换。把A3迟滞从2dB调整为4dB，同时把TTT从160ms调整到240ms后，切换带位置优化到了信号交叠区，MOS从2.5回升到3.9。这个案例给我最大的提醒是：MOS问题的表象是“语音质量差”，本质却常常是移动性管理问题。

注意：MOS测试时严禁开蓝牙耳机、关屏、插拔充电线等操作，这些行为会导致终端射频发射功率异常或Test软件记录异常，让测试结果失真。多次复测才能得到稳定统计数据，建议每个场景至少复测3次。

4. 随机接入失败排查：从消息流倒推每一类失败

4.1 随机接入流程与失败的高发场景

随机接入是终端和基站建立联系的第一道门槛。无论是LTE还是5G NR，随机接入场景都很多：终端初始接入（RRC_IDLE态发起业务）、RRC连接重建、切换时的目标小区接入、上行失步后的调度请求、RRC_INACTIVE态恢复等等。任何一个场景随机接入失败，最终都表现为用户无法上网、语音呼叫失败、切换中断。

LTE和5G NR都支持四步随机接入：Msg1终端发送PRACH前导码，Msg2基站回复随机接入响应（RAR），Msg3终端发送调度传输（携带RRC消息或C-RNTI MAC CE），Msg4基站发送竞争解决信息。5G NR还引入了两步随机接入（MsgA/MsgB）来降低时延，但主流的兼容性和配置还以四步为主，实际工程问题也多集中在四步流程。

随机接入失败往往是“流程中某一步没走通”，所以排查的核心方法是把问题定位到具体是哪一条消息失败、失败的是哪一类场景，然后针对性地检查对应参数。

4.2 失败分类定位法：Msg1发不出、Msg2收不到、Msg3冲突

我把随机接入失败分成三类，每一类的排查方向都不一样。

第一类，Msg1没有响应。终端发了PRACH前导码，但基站一直没有下发RAR。可能原因有：PRACH的发射功率不足，上行覆盖差，preamble接收目标功率设置过低；PRACH资源配置和实际时隙错位，比如TDD上下行配比与PRACH配置的时域位置冲突；上行时隙存在干扰，基站收不到前导；以及小区prach-CONFIG INDEX配错导致基站监听的前导格式和终端发送的不一致。排查时先在后台看该小区PRACH检测成功率，该指标直接反映前导码有没有被基站正确检测；再测上行干扰，确认是否被外部干扰源压制；最后核对PRACH配置参数。

第二类，Msg2接收失败。终端发出Msg1后收到了RAR，但一直没有进入Msg3调度。常见原因是RAR窗口配置太短，终端还没来得及解码就超时了；或PDCCH公共搜索空间的聚合级别配置太低，RAR承载在PDCCH上的DCI没有被边缘弱信号终端解码成功。这类问题通常集中在小区边缘用户上。调整方向是适当增大RAR窗口长度（从5ms加大到10ms），同时验证公共搜索空间的聚合级别配置，避免RAR DCI发送功率不足。

第三类，Msg3竞争冲突。多个终端同时选择相同的前导码，或者Msg3的C-RNTI MAC CE发生冲突，竞争解决失败。高话务场景下特别容易发生。核心参数是竞争解决定时器contentionResolutionTimer，设置过短导致终端来不及收到Msg4就判定失败；以及前导码分组配置，如果每个SSB映射的preamble数量过少，高负载时冲突概率飙升。此时还需要看preamble的distribution是否均匀，如果大量终端集中在某几个preamble上，就会出现“部分preamble疯抢、其他preamble空闲”的失衡现象。

4.3 PRACH功率、前导格式与参数调整

随机接入相关的参数，重点盯三块：功率参数、前导格式、时频资源。

功率参数这一块，preambleInitialReceivedTargetPower定义了基站期望的preamble接收功率，典型值在-104dBm到-110dBm。如果设得太低，边缘终端需要很大的发射功率来补偿，而终端最大发射功率有限，导致前导根本达不到目标接收功率；powerRampingStep则控制终端在Msg1失败后逐步抬升发射功率的步长，典型2dB或4dB，步长太小，终端需要多次重试才能达到足够发射功率，时延增加；步长太大，容易造成“功率过冲”增加干扰。maxNumPreambleAttempt决定终端最多尝试多少次，次数太少会提前放弃。现场处理“电梯口弱覆盖随机接入失败”，最常见的操作就是把prach-ConfigIndex往小干扰窗口调整，同时抬升前导初始目标功率，有效缓解边缘接入失败。

前导格式方面，LTE的format 0/1/2/3对应不同的覆盖半径，format 3覆盖能力最强，适合超远覆盖场景，但占用时域资源多；5G NR的prach长短前导更灵活，长序列如A1/A2/A3/B1/B2/B3/C2等，短序列适用于小包场景。配置前导格式时，要结合小区覆盖半径，注意Protection Period需求，防止终端信号回传时跨时隙干扰。尤其是超远覆盖基站，如果前导格式选择不当，基站检测不到前导或者检测到但TA超范围，都会表现为“接入不成功”。

时频资源方面，PRACH频域起始位置和PRACH MaskIndex决定前导可用的物理资源块。如果PRACH频域位置和PUSCH的跳频配置重叠，导致上行干扰集聚在前导所在的频域位置，也会造成基站解调前导失败。

4.4 5G NR中SSB与波束对随机接入的影响

5G NR的随机接入和LTE有一个显著区别：终端选择前导的依据是SSB索引，也就是说SSB波束的覆盖和配置直接影响随机接入性能。

如果SSB波束覆盖存在空洞，或者波束增益不够，终端的同步和下行信号接收质量差，Msg1发射前连下行同步都做不好，随机接入自然失败。排查时关注SSB的RSRP分布和波束数量配置。通常SSB波束数量可配置为1/4/8个，波束过多会导致每个波束增益下降，边缘覆盖变差；过少会导致水平覆盖不完整。需要结合站型和场景做平衡。

另外，5G的PRACH Occasion映射到SSB的关联关系非常关键。每个SSB关联的PRACH Occasion数量和前导数量要合理。如果关联关系配错，终端在一个SSB波束下找不到可用的PRACH资源，也会触发前导发送失败。常见于NSA组网时，终端先接入LTE再添加NR辅小区，如果NR小区的SSB与PRACH映射参数配置不一致，会表现为辅小区添加失败率高。

处理NR随机接入问题时，我还习惯看两个指标：gNodeB检测到的PRACH能量分布是否和SSB波束覆盖一致，以及RACH尝试成功率分布是否在某个SSB波束下特别低。如果某个波束下的成功率明显偏低，优先怀疑该波束覆盖区域存在弱场或干扰，而不是盲目调整全局参数。

5. 常见问题与排查技巧实录

5.1 实战中踩过的坑

第一坑：把手机显示信号满格当成无线环境好。手机信号显示是RSRP级，不代表SINR就一定好。信号满格但SINR只有3dB的情况很常见，高层遮挡、异频邻区干扰、系统内模三干扰都能造成这种现象。所以测试时一定看两层：RSRP和SINR，两边都好才算真无线环境好。

第二坑：不做基线对比直接调参数。很多参数调完以后，你无法判断是参数生效还是无线环境变了。正确做法是调整前先测白数据，调整后同步同路线再测，并保留后台KPI的前后对比。没有基线的优化等于瞎调。

第三坑：忽视后台告警和光模块告警。有一次排查随机接入失败，查了三天参数都没找到问题，最后发现是基站的RRU光模块接收功率劣化，RRU和BBU之间频繁闪断导致前导检测时好时坏。所以拿到问题的第一件事，先把网管的硬件告警、传输告警、光模块劣化告警过一遍。别看这动作简单，能省下一大半排查时间。

第四坑：测试软件或终端设置错误。做VoLTE MOS测试时，测试终端没开启VoLTE开关，导致手机全部回落到2G/3G做CSFB，测出来的MOS当然低得离谱。这个错误在行业里出现过很多次，每次都要反复确认测试环境才敢下结论。排查问题前先花两分钟检查测试配置，绝对不亏。

第五坑：外部干扰排查拖太久。上行干扰导致速率低和接入失败的案例很多，外部干扰源可能是私装放大器、大功率对讲机、伪基站或老旧广电设备。扫频排查需要时间和设备，有时候确实难，但如果一直拖着不做，所有空口优化都是白做。干扰问题一定优先定位干扰源。

5.2 排查效率提升：信息收集清单与工具速查

为了不重复跑现场，我在出发测试前会准备一张标准信息收集清单：问题现象（发生时间、地点、业务类型、用户数）、问题小区（基站名、小区号、频段、PCI）、后台KPI（接通率、掉线率、切换成功率、干扰水平、RRC重建率）、测试计划（路线、时段、终端型号、软件版本）。这张清单逼迫相关同事一次性给全信息，避免到了现场发现缺这个缺那个。

常用工具方面，DT测试常用鼎利或Pioneer/Probe，后台分析用MapInfo或Atoll，信令分析用Wireshark配合基站跟踪日志。这些工具不必一次全掌握，但至少要做到：测出来的数据会导、会看统计、会截图存证。截图和地理化信息存储特别重要，每次测试完都要做资料归档，不然事后追溯问题，数据丢了等于白测。

5.3 大数据分析思路：从单点问题到全网隐患

除了处理单个投诉，我现在更推荐用大数据方法做“主动排查”。把全网小区按周粒度做聚类分析，比如MCS分布异常的小区、上行干扰抬升超过阈值的小区、随机接入成功率低于99%的小区，全部打标签生成隐患清单。每周盯一遍隐患清单，很多问题在用户投诉前就被消除了。

这套思路用SQL或Excel都能做。以随机接入为例，我每周导一次全网RRC连接建立成功率、RACH尝试次数和PRACH检测成功率，按小区排序，筛选出成功率低于基准值的小区，然后去核查这些小区的干扰和配置。几次实际操作下来，发现的隐患往往比投诉来得更早。用数据驱动支撑网络优化，才是这个行业未来的工作方式。

这几年做LTE/5G网络优化，最大的体会是：任何一次网络问题排查，本质都是“数据的一次认真对话”。先把各类数据摸清，再让数据告诉你问题所在。链路这一头是用户感受到的业务体验，那一头是基站、核心网、传输层层叠叠的系统，但只要我们保持清晰的排查思路，再复杂的问题都能一步一步拆出来。

最后再分享一个小技巧：建议给自己维护的每个重点小区都建一份“小区病历卡”，记录历史故障、历次参数调整、测试数据和优化动作。下次再出问题，翻开病历卡两分钟就能找到线索，效率能提升一大截。排查网络问题和看病一样，了解“病史”永远是第一步。