Network detection method, device and equipment for mobile terminal

Abstract

The application discloses a network detection method, device and equipment of a mobile terminal. The method can be applied to the fields of financial technology and medical health, and detects whether an application layer can access a corresponding service server. In response to detecting that the application layer cannot access the service server, it is determined that a network is abnormal, and deep detection is performed to obtain a deep detection result. The deep detection result at least includes a DNS server list, a service server list and a connection result of the service server. The network abnormality reason is determined based on the deep detection result to be from the DNS server, the service server or network routing. In the application, the abnormality is detected in time before the problem extends and expands, blind manual testing of the user is avoided, and through in-depth analysis of the deep detection, the network abnormality reason is distinguished to be from the DNS server, the service server or network routing, and the detection precision of the network abnormality detection of the mobile terminal is improved.

Description

Technical Field

[0001] This application relates to the field of network anomaly detection technology, which can be applied in the fields of fintech and healthcare, and particularly to network detection methods, devices and equipment for mobile terminals. Background Technology

[0002] In financial transaction payment scenarios such as QR code payments, money transfers, and wealth management product subscriptions, facial recognition, SMS verification code acquisition, and fingerprint / face payment authorization are required. If the SMS verification code is not received for an extended period, or if the video stream upload fails during facial recognition, it's necessary to diagnose whether a connection to public Wi-Fi is restricting the SMS / MMS channel. In medical mobile terminal scenarios, medical apps involve patient privacy, vital sign data, and remote diagnosis and treatment. Network detection emphasizes data integrity, low latency, and high availability. For example, in remote consultation / video diagnosis scenarios, when a mobile terminal experiences network anomalies, anomaly detection often relies on manual user intervention. For instance, if a user cannot hear the other party clearly during a voice call or a video conference drops, anomaly detection is only triggered when the user notices it and takes manual action. Network anomaly detection is generally triggered after the anomaly has spread, resulting in a poor user experience.

[0003] Currently, some network diagnostic processes typically only perform simple connectivity tests such as Ping tests. For example, when DNS resolution fails, existing solutions cannot distinguish whether the problem lies with the DNS server, network routing, or the target server, leading to an inability to accurately diagnose the cause of network anomalies. Some network diagnostic processes also involve blind testing, such as randomly turning airplane mode on and off, repeatedly switching between Wi-Fi and cellular data, and resetting network settings. These attempts to restore the network through random or exhaustive operations lack logical direction. Neither of these approaches can promptly and deeply analyze the root cause of network problems, resulting in low diagnostic efficiency. Therefore, existing technologies suffer from low detection accuracy for network anomaly detection on mobile terminals. Summary of the Invention

[0004] This application provides a method, apparatus, and device for network detection of mobile terminals, which can solve the technical problem of low detection accuracy in network anomaly detection of mobile terminals.

[0005] In a first aspect, embodiments of this application provide a network detection method for a mobile terminal, the network detection method for the mobile terminal comprising:

[0006] In response to the detection command of the target mobile terminal network, detect whether the application layer can access the corresponding business server;

[0007] In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and a deep detection is performed to obtain the deep detection results, which include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers.

[0008] Based on the deep detection results, it was determined that the network anomaly originated from the DNS server, the business server, or the network routing.

[0009] In some embodiments, in response to detecting that the application layer service server is inaccessible, a network anomaly is determined, and deep detection is performed to obtain deep detection results, including:

[0010] In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and the IP connectivity result of the business server to the application layer is obtained.

[0011] If all service servers in the IP connectivity results fail to connect, then the DNS server is recorded in the DNS server list, and the connectivity result of the service server is marked as unconnected.

[0012] If some service servers fail to connect in the IP connectivity results, the corresponding service servers that failed to connect are recorded in the service server list, and the connectivity results of the service servers are marked as partially connected.

[0013] If all service servers in the IP connectivity results are successfully connected, then the connectivity result of the service servers is marked as fully connected.

[0014] The deep detection result is obtained by packaging the DNS server list, the business server list, and the connectivity results of the business servers.

[0015] In some embodiments, based on the deep detection results, determining that the network anomaly originates from a DNS server, a service server, or a network route includes:

[0016] If the connectivity result of the business server is not connected, then the cause of the network anomaly is determined to be at least the DNS server.

[0017] If the connectivity result of the service server is partial connectivity, then the cause of the network anomaly is determined to be at least one of the service servers in the service server list.

[0018] If the connectivity result of the business server is fully connected, then the cause of the network anomaly is determined to be at least due to the network routing.

[0019] In some embodiments, after determining, based on the deep detection results, that the network anomaly originates from a DNS server, a service server, or a network route, the process includes:

[0020] If it is determined that the cause of the network anomaly is at least due to the network routing, then the detection is performed layer by layer in the order of device layer, link layer, Internet layer and authentication layer to obtain the detection result of the current layer;

[0021] If the current layer result is abnormal, then the abnormal network route is determined to originate from the current layer.

[0022] In some embodiments, if it is determined that the network anomaly is caused at least by the network routing, then the detection is performed layer by layer in the order of device layer, link layer, Internet layer, and authentication layer to obtain the detection result of the current layer, including:

[0023] If it is determined that the network anomaly is caused by at least the network routing, then obtain the network information of the target mobile terminal at the device layer.

[0024] In response to determining that the link layer is currently connected to the network based on the network information, the connectivity of the Internet layer is detected through a preset public network;

[0025] In response to the detection of Internet layer connectivity, the authentication layer checks whether webpage authentication has been completed.

[0026] In some embodiments, if the current layer result is abnormal, after determining that the abnormal network route originated from the current layer, the method further includes:

[0027] Based on the abnormal device layer, a pop-up prompts to enable network data;

[0028] Based on the abnormal link layer, a new request is made to refresh the IP address;

[0029] Based on an abnormal internet layer, a prompt to switch networks is displayed;

[0030] Based on the exception authentication layer, a page awaiting authentication is returned.

[0031] In some embodiments, in response to a detection command to detect the target mobile terminal network, detecting whether the application layer can access the corresponding service server further includes:

[0032] In response to a lightweight detection command for detecting a target mobile terminal network, a detection request is initiated to a preset detection point, and the response delay time is recorded. The lightweight detection command is triggered by the application switching from the background to the foreground.

[0033] If the request is successful and the response delay time is within the preset delay range, the network is determined to be normal and the detection is exited.

[0034] If the request is successful and the response delay time exceeds the preset delay range, a weak network prompt is output and the detection is exited. The weak network prompt will not interrupt the user's current operation.

[0035] If the request fails or the response delay exceeds the preset delay range, the current detection result will be displayed and the detection will be exited.

[0036] In some embodiments, before detecting whether the application layer can access the corresponding service server in response to a detection command for detecting the target mobile terminal network, the process includes:

[0037] In response to a cold start of the application, an application trigger signal is generated;

[0038] In response to network type switching, a network state change signal is generated at the corresponding trigger frequency;

[0039] In response to network request errors or page errors, generate an interaction error trigger signal;

[0040] In response to user operation detection data, a manual trigger signal is generated;

[0041] In response to the detection of any one of the application trigger signal, the network status change signal, the interaction anomaly trigger signal, and the manual trigger signal, a detection command for detecting the target mobile terminal network is generated.

[0042] Secondly, embodiments of this application also provide a network detection device for a mobile terminal, the network detection device for the mobile terminal comprising:

[0043] The access detection unit is used to respond to the detection command of the target mobile terminal network and detect whether the application layer can access the corresponding business server.

[0044] The deep detection unit is used to determine a network anomaly in response to the detection that the application layer cannot access the business server, and to perform deep detection to obtain deep detection results. The deep detection results include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers.

[0045] The determining unit is used to determine, based on the deep detection results, whether the network anomaly originates from a DNS server, a business server, or a network route.

[0046] Thirdly, embodiments of this application also provide a network detection device for a mobile terminal, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0047] This application provides a network detection method, apparatus, and device for mobile terminals. The method includes: responding to a detection command for detecting the network of a target mobile terminal, detecting whether the application layer can access the corresponding service server; responding to the detection that the application layer cannot access the service server, determining a network anomaly, and performing deep detection to obtain deep detection results, the deep detection results including at least a DNS server list, a service server list, and the connectivity results of the service servers; and based on the deep detection results, determining that the network anomaly originates from a DNS server, a service server, or a network route. In this application, timely detection of anomalies before the problem escalates and expands avoids users blindly performing manual tests, and through in-depth analysis of deep detection, distinguishing whether the network anomaly originates from a DNS server, a service server, or a network route, improves the detection accuracy of network anomaly detection for mobile terminals. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 A flowchart illustrating the network detection method for a mobile terminal provided in an embodiment of this application;

[0050] Figure 2 A schematic block diagram of a network detection device for a mobile terminal provided in an embodiment of this application;

[0051] Figure 3 This is a schematic diagram of the structure of the device in one embodiment of this application;

[0052] Figure 4 This is another structural schematic diagram of the device in one embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. The user personal information involved in the embodiments of this application is obtained by an entity authorized (with the knowledge and consent) or fully authorized by all parties through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0055] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0056] It should also be understood that the terminology used in this application specification is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this application specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0057] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0058] In financial transaction payment scenarios, such as QR code payments, money transfers, and wealth management subscriptions, facial recognition, SMS verification code acquisition, and fingerprint / face payment authorization are required. If the SMS verification code is not received for an extended period, or if the video stream upload fails during facial recognition, it's necessary to diagnose whether a connection to public Wi-Fi is restricting the SMS / MMS channel. In medical mobile terminal scenarios, medical apps involve patient privacy, vital sign data, and remote diagnosis, such as remote consultations / video consultations. Network testing in these scenarios emphasizes data integrity, low latency, and high availability. Currently, for ordinary users, they lack the knowledge of layered diagnostics and cannot distinguish between the physical device layer, the link layer, the internet layer, the authentication layer, and the application layer. When an anomaly occurs, their only recourse is to try switching the device on and off. For operations and maintenance personnel, frontline support staff face immense pressure from work orders, and average processing time is strictly assessed. Systematic diagnosis requires users to provide a large amount of information, such as screenshots, speed test results, and specific time periods, resulting in high communication costs. Therefore, restarting becomes the most efficient method. Regardless of the anomaly, such as poor signal, slow internet speed, or inability to connect, the common practice is to restart the mobile device and router. Restarting can resolve some cache or deadlock issues, but it's ineffective for fundamental causes like signal blind spots, ISP speed limits, DNS misconfigurations, or unpaid bills; it's purely a matter of luck. Both mobile operating systems and home routers offer extremely limited diagnostic tools for users and maintenance personnel. In most cases, users cannot see key indicators, such as repeatedly turning airplane mode on and off, constantly switching between Wi-Fi and cellular data, casually changing the Access Point Name (APN), or resetting network settings. There's a lack of categorization of anomalies; for example, is Wi-Fi completely unusable, or only specific apps? Randomly changing the APN can completely disable devices that were previously able to connect to the internet.

[0059] The target mobile terminal of this application is equipped with a preset network layering model, which includes a device layer, a link layer, an internet layer, an authentication layer, and an application layer that represent the physical hardware in the mobile terminal.

[0060] The device layer is the physical foundation layer of the entire network layered model, responsible for verifying whether the hardware components of the mobile terminal are in a functional state. Only after this layer passes inspection can the diagnostics of higher layers be meaningful. The objects in the device layer include physical hardware, baseband, antenna, SIM card, and radio frequency circuitry.

[0061] The device-level checks include: if anomalies are detected such as baseband unresponsiveness or firmware crashes, it indicates a communication chip malfunction, and restarting the phone is recommended. If abnormal transmit power or excessively high VSWR is detected in the antenna status, it indicates the antenna may be damaged, and it is recommended to have it checked at a repair shop.

[0062] The link layer is responsible for confirming whether the mobile terminal can successfully connect to the nearest network access point. In cellular networks, this is the base station; in Wi-Fi networks, it's a router or access point (AP). The link layer solves the problem of whether a connection can be established. It not only detects whether a connection can be established, but also whether the connection is stable. For example, it detects the number of link reconnections in the past minute; if it exceeds a threshold, it is considered frequent link jitter.

[0063] The Internet layer is responsible for confirming whether a network layer connection has been established, that is, whether the terminal can communicate with the outside world via IP at the network layer. It solves the problem of whether communication can proceed after a connection is established, corresponding to the network layer in the TCP / IP model.

[0064] The authentication layer is responsible for verifying whether a terminal's identity is allowed to access the network. Many network problems are not due to physical connectivity issues, but rather to failed identity verification leading to a denial-of-service response. This layer exists independently of the internet layer because sometimes a terminal can obtain an IP address and ping successfully, but cannot pass through the operator's authentication gateway.

[0065] The application layer is responsible for verifying whether data interaction for a specific application or service is normal. Even after the first four layers have passed, users may still encounter problems such as "a game cannot be opened" or "a webpage displays a certificate error".

[0066] The embodiments provided in this application Figure 1 This is a flowchart illustrating a network detection method for a mobile terminal provided in an embodiment of this application. The network detection method for the mobile terminal includes the following steps S110-S130:

[0067] S110. In response to the detection command of the target mobile terminal network, detect whether the application layer can access the corresponding service server.

[0068] The application layer is a logical layer in the network protocol stack. Essentially, it's a set of communication rules responsible for providing network services such as data formatting, connectivity, and synchronization for application processes. It encompasses protocols like HTTP, FTP, SMTP, DNS, and TLS, and resides at an abstract network layer. Its operation involves encapsulating business data into packets for transmission to the lower layers.

[0069] A business server is a physical or virtual machine that has an operating system and applications installed. Its responsibilities include executing business rules, calculations, process control, and data processing. It contains code, database connection pools, and caches, and is deployed in cloud instances or containers. Its working method is to receive user requests, call business logic, and generate response data.

[0070] In this embodiment, the application layer is responsible for verifying whether the data interaction of a specific application or service is normal. Users may encounter problems such as "a game cannot be opened" or "a webpage displays a certificate error".

[0071] The process of an application layer accessing a business server typically involves multiple stages, including network connection, protocol interaction, authentication, and business logic processing. Access failures can occur in several ways: First, network connectivity issues, such as a physical link interruption or switch / router failure, preventing data packets from the application layer from reaching the business server. Second, authentication and authorization failures, such as the application layer failing to provide valid credentials, expired credentials, or incorrect username / password; the business server's access control list may also reject the request. Third, excessive network latency, or the business server's processing time exceeding the timeout threshold set by the application layer, causing the application layer to actively disconnect.

[0072] The process of the application layer accessing the business server is based on the DNS server (Domain Name System).

[0073] In the process of accessing a business server at the application layer, a DNS server acts like a navigator, translating human-rememberable domain names into IP addresses required for machine addressing. This is used at the application layer to access the business server based on easily remembered domain names, but the network world only recognizes IP addresses, and a DNS server helps to find the service corresponding to that IP address.

[0074] The entire access process is an addressing journey. First, when a user enters or clicks a domain name at the application layer to initiate a request, such as https: / / api.example.com / login; second, DNS resolution is triggered, and the target mobile terminal first queries a configured DNS server, such as a public DNS, for the IP address of the domain name; third, the DNS server responds, and after a series of recursive or iterative queries, it finally returns a specific IP address; fourth, a connection is established, and only after the target mobile terminal obtains this IP address will it access the business server through this IP, initiating a TCP connection, and subsequently conducting application layer communication such as HTTP.

[0075] As an example, the network detection device on the mobile terminal obtains local logs from the business server. These local logs allow the device to determine whether the application layer can access the corresponding business server. This is because for each received request, the log prints "Received request from xx". If the log shows an exception stack trace, connection refusal, or no corresponding access record, it indicates that the request never reached the application layer, and the application layer cannot access the business server.

[0076] This embodiment determines the layer from which the anomaly originated based on whether the application layer can access the corresponding business server, and then traces the cause of the anomaly.

[0077] Prior to S110, including A1-A5:

[0078] A1. In response to application cold start, generate application trigger signals;

[0079] In the above steps, there are several conditions that trigger the detection of whether the application layer can access the corresponding business server. For example, during an app cold start, a complete network diagnostic process is executed after the application layer initialization is complete to ensure that the network status is normal when the user enters the application. In particular, before executing the complete network diagnostic process, it is necessary to first determine whether network permissions have been obtained; execution can only proceed after permissions have been obtained.

[0080] After determining that the application has started cold, an application trigger signal is generated, which is part of the APP's lifecycle.

[0081] App cold start refers to the process of an application being opened by a user for the first time before the system process is running, or the system being restarted after being killed due to insufficient memory or other reasons.

[0082] There are two ways to launch an app: cold start and warm start.

[0083] For cold starts of an app, the application process does not exist in system memory. The system needs to create the process from scratch, load the application code, initialize resources, and build the page. This is the most complete startup method. In this embodiment, when the system process starts running the app's cold start, an application trigger signal is generated simultaneously with the completion of the homepage initialization. This avoids the user seeing a blank page or error message before the network check begins, improving the first-screen experience. Network diagnostics and homepage rendering are performed in parallel, and network readiness checks are completed in advance at the entry point.

[0084] Ensure network availability when users access the homepage. Subsequent network diagnostics should be performed as a separate background task, independent of the application's homepage initialization, to avoid increasing startup time.

[0085] When an app cold starts, the user's first instinct upon opening the app is to immediately see and interact with the content. If the network check is only performed when the user clicks a button that requires a network connection, the user will experience a waiting chain of "click, check, request, feedback." Cold start detection hides network diagnostics behind the launch screen or homepage initialization, so the network status is clear when the user completes the startup process and enters the interface. If the network is abnormal, an offline mode or retry prompt can be displayed immediately, avoiding a blank screen or endless loading loop for the user.

[0086] The cold start process typically involves time-consuming operations such as page rendering, local database loading, and configuration reading. Placing network detection in a background thread to run in parallel with these tasks allows network probing to be completed during the startup window. As long as the detection logic is designed properly, it will not extend the user's interactive time.

[0087] A2. In response to network type switching, a network state change signal is generated at the corresponding trigger frequency.

[0088] The trigger condition for checking whether the application layer can access the corresponding business server is as follows: for example, when the target mobile terminal's network begins to switch. As an example, when a switch from 4G to Wi-Fi is detected, or vice versa, a network quality check is automatically triggered. Specifically, it is not triggered immediately, but rather after a 15-second delay.

[0089] When the system detects a network type switch, such as switching from Wi-Fi to cellular, it doesn't immediately send a network status change signal. Instead, it initiates a preset delay. Only after consistently and stably detecting the switch and the delay has ended will a signal be generated. This design avoids frequent false triggers caused by signal jitter. In areas with unstable network coverage, such as elevators, basements, or while moving, devices may frequently switch between Wi-Fi and cellular networks. If a signal were sent immediately after each switch, the system would receive a large number of invalid status change notifications in a short period. By introducing a preset delay, these brief and unstable switches can be filtered out, and a signal is only sent after the network status has stabilized at a certain type.

[0090] If, during the waiting period, multiple network type switches are detected, such as frequent transitions between Wi-Fi and cellular, the system will not generate a signal for each switch. Instead, it will control the signal output according to a preset trigger frequency. Even if multiple switching events occur, the signal generation frequency will not exceed the set upper limit, thus avoiding excessive invalid signals due to frequent network fluctuations. Each network state change signal may trigger a series of subsequent operations, such as re-initiating network requests, refreshing the UI, logging, or executing business logic. If the signals are too frequent, they will consume additional CPU, power, and memory. This application reduces the system load and lowers system resource consumption by controlling the trigger frequency, such as limiting it to a maximum of once every 60 seconds. When a user moves around at the edge of the signal range, if the application interface constantly switches states due to repeated network type changes, it will appear laggy, degrading the user experience.

[0091] Furthermore, to prevent frequent operations, the system controls the trigger frequency to ensure that the diagnosis is triggered only once within a reasonable time interval.

[0092] A3. In response to network request errors or page errors, generate an interaction error trigger signal;

[0093] During application runtime, in addition to proactive pre-checks during the cold start phase, network diagnostics can be automatically triggered when user interaction anomalies occur, enabling real-time and precise problem localization. This embodiment covers two typical interaction anomaly scenarios: network request anomalies and H5 page loading anomalies.

[0094] The first scenario is triggered by abnormal network requests. When the application communicates with the backend service via HTTP / HTTPS protocol, if the following abnormalities occur, the system will automatically start the network diagnostic process.

[0095] When DNS resolution fails and a domain name cannot be resolved to an IP address, it may indicate a network configuration error, unreachable DNS service, or that the current network cannot access the external network.

[0096] Transport layer errors, including connection timeout, connection refused, and timeout, often indicate network connectivity issues, firewall blocking, or closed server ports.

[0097] If the deep detection result indicates a connection timeout, the timeout time and route tracing result are recorded, and it is determined whether the problem is due to network congestion or route interruption. Based on the determination result, subsequent anomaly handling steps are performed.

[0098] The user is notified that network latency is too high and the request has timed out. The backend records the timeout period and route tracing results to determine if the issue is caused by network congestion or route interruption. Based on the determination, subsequent exception handling steps are taken.

[0099] When an application layer error occurs, an HTTP status code exception is received, such as a 4xx / 5xx error. Although some of these errors are caused by server-side business logic, they may also originate from network problems if accompanied by changes in the network environment.

[0100] The second scenario is triggered by H5 page loading errors. For H5 pages embedded in the application, when a page loading timeout or failure occurs, network diagnostics are automatically triggered to help distinguish whether the root cause of the problem lies in the network environment or the H5 server.

[0101] A4. Generate a manual trigger signal in response to user operation detection data;

[0102] Although this application adds several ways to automatically trigger network anomaly detection, it still retains the method of manual triggering by the user.

[0103] Providing users with opportunities to manually trigger actions includes weak network alerts or hidden debugging mechanisms. A weak network alert displays a warning bar below the navigation bar when the page is offline, prompting the user to click and enter a network testing page. Hidden debugging mechanisms are covert debugging and testing mechanisms in software development. These are hidden, non-public entry points or methods within an application. Common forms include repeatedly clicking the version number, using specific gestures on a particular page, shaking the device, and entering commands in the debugging console. For example, by accessing the debugging page through "My," "Settings," "About," or by long-pressing / clicking the app icon three times, users can click "Network Testing" to manually trigger diagnostics. A manual trigger signal is generated in response to these user commands for network testing.

[0104] A5. In response to detecting any one of the application trigger signal, the network status change signal, the interaction anomaly trigger signal, and the manual trigger signal, a detection command for detecting the target mobile terminal network is generated.

[0105] In existing technologies, the triggering method for generating detection commands to detect the target mobile terminal's network is singular. Current mobile applications' network diagnostic functions largely rely on manual user triggering or simple network status change detection. Generally, detection commands are only generated after an anomaly has occurred and the user has begun detecting it. For example, if a user cannot hear the other party clearly during a voice call on a mobile terminal, or if a video conference disconnects, anomaly detection is only triggered when the user directly notices it and takes manual action. Network anomaly detection is typically triggered after the anomaly has spread, resulting in a poor user experience.

[0106] However, in this application, the generation of the detection command for the target mobile terminal network does not rely on manual user operation. Instead, it intervenes promptly before or during a problem, generating the detection command in a timely manner. The detection command for the target mobile terminal network is based on any one of the following: an application trigger signal, the network state change signal, the interaction anomaly trigger signal, and the manual trigger signal. As long as any one of these is detected, the generation of the detection command is directly triggered. Therefore, it is only necessary to check the presence of any one of these trigger signals before generating the detection command.

[0107] In some embodiments, S110 further includes S1101-S1104:

[0108] For app launch methods where the application process remains in system memory (meaning the application is already running in the background and the user switches it to the foreground), there's no need to rebuild the process; simply restore the page from the background to the foreground. For app hot-start methods, network detection based on the network layering model is no longer used, as this is considered deep detection. Lightweight detection should suffice.

[0109] S1101. In response to a lightweight detection command for detecting the target mobile terminal network, a detection request is initiated to a preset detection point, and the response delay time is recorded. The triggering method of the lightweight detection command includes the application switching from the background to the foreground.

[0110] When an application switches from the background to the foreground—that is, when the user reopens or switches to the application—the system automatically triggers a lightweight network connectivity check. This check performs only an HTTP latency test, quickly determining network availability with minimal overhead. A lightweight detection signal is generated in response to the application switching from the background to the foreground.

[0111] This detection method is designed to be lightweight, consisting of only one step. It initiates HTTP HEAD or GET requests to one or more pre-defined stable probe points, such as self-built / ping interfaces, and records the response time. It does not perform deep DNS resolution analysis, obtain Wi-Fi details, conduct multi-round authentication checks, or collect information such as MAC addresses. The timeout for a single request is controlled within 2 seconds to ensure that even network congestion will not cause the task to hang for an extended period.

[0112] By listening to application lifecycle events, a detection is triggered when the application re-enters the foreground and the interface is about to become visible to the user. To avoid competing for resources with interface rendering, the detection task is placed in a background thread and executed in a high-priority but non-blocking manner.

[0113] If a lightweight detection signal is detected, a request is sent only to a preset detection point, and the response delay time is recorded.

[0114] S1102. If the request is successful and the response delay time is within the preset delay range, then the network is determined to be normal and the detection is exited.

[0115] S1103. If the request is successful and the response delay time exceeds the preset delay range, output a weak network prompt and exit the detection. The weak network prompt will not interrupt the user's current operation.

[0116] S1104. If the request fails or the response delay time exceeds the preset delay range, the current detection result will be displayed and the detection will be exited.

[0117] If the request is successful and the delay time is within the preset delay range, the network connectivity is determined to be normal; if the request fails or the delay time is outside the preset delay range, the diagnostic result is recorded and the status is marked. If the user is subsequently detected to request the network again, the user is prompted based on the marked status.

[0118] If the request is successful and the delay time is outside the preset delay range, the application will be given a weak network warning, and the user's current operation will not be interrupted when the weak network warning is given.

[0119] If the request is successful and the delay is within an acceptable range, such as <1000ms, the network connectivity is considered good, and normal service should be maintained without displaying any prompts to the user.

[0120] If a request fails or times out, it is determined that there may be a network problem. However, instead of immediately displaying an error message, the diagnostic results are recorded, and a soft state indicating a network issue requiring attention is marked. Subsequent operations requiring network connectivity are then guided by this new state.

[0121] If a high latency is detected but the connection is still established, a weak network warning can be provided within the application without interrupting the user's current operation.

[0122] This lightweight detection method exits immediately after the test to avoid impacting user experience. Because the test is executed asynchronously in the background and involves only a single lightweight request, it will not cause a blank screen, lag, or pop-up interference, and the user will hardly notice the detection process. It quickly responds to network changes. While the application is in the background, network switching may occur, such as moving from Wi-Fi to cellular. Triggering the test in the foreground allows for timely acquisition of the latest network status, preventing the application from initiating requests using outdated network information. Compared to complete network diagnostics, which include DNS, authentication, and multi-server testing, lightweight detection significantly reduces power consumption, data usage, and time consumption, making it suitable for high-frequency triggering scenarios.

[0123] S120. In response to detecting that the application layer cannot access the business server, a network anomaly is determined, and a deep detection is performed to obtain the deep detection result. The deep detection result includes at least a DNS server list, a business server list, and the connectivity result of the business server.

[0124] The application layer testing phase then begins, aiming to determine the reachability of the application's core business servers. This involves deep connectivity testing of the service domain, including DNS resolution and IP connectivity testing, to obtain detailed diagnostic data. As an example, the deep testing results are presented in JSON format for easy parsing by the program.

[0125] S120 includes S1201-S1205:

[0126] S1201. In response to detecting that the application layer cannot access the business server, a network anomaly is determined, and the IP connectivity result of the business server to the application layer is obtained.

[0127] S1202. If all service servers in the IP connectivity results fail to connect, then the DNS server is recorded in the DNS server list, and the connectivity result of the service server is marked as not connected.

[0128] S1203. If some service servers in the IP connectivity results fail to connect, the corresponding service servers that failed to connect are recorded in the service server list, and the connectivity result of the service servers is marked as partially connected.

[0129] S1204. If all service servers in the IP connectivity results are successfully connected, then mark the connectivity results of the service servers as fully connected.

[0130] S1205. The DNS server list, the business server list, and the connectivity results of the business servers are packaged to obtain the depth detection result.

[0131] Deep testing allows for precise identification of whether the cause is a DNS resolution failure or an unreachable specific IP address.

[0132] First, confirm that the domain name can be correctly resolved to an IP address. This can be done using various tools and DNS servers. Collect key data, including the list of resolved IP addresses, response time, authoritative server information, and whether there are any resolution errors or anomalies.

[0133] After obtaining the IP address, the connectivity between the network layer and the transport layer needs to be tested.

[0134] Connectivity includes ICMP connectivity and port connectivity. When testing ICMP connectivity, the ping command is used to check if the target IP is reachable and to obtain latency and packet loss rate. By examining each hop the data packets travel through, network bottlenecks or outage points can be located, and real-time display of packet loss rate and latency changes at each hop helps to quickly assess network quality. When testing port connectivity, services typically listen on specific ports such as 80, 443, and 22. Testing whether TCP ports are open indicates port reachability; a successful connection indicates port availability. This stage collects ping latency and packet loss rate, latency and packet loss at each node in the routing path, and port openness.

[0135] During the connectivity test, the target business server that cannot be connected among multiple business servers is identified as an abnormal server. The reasons for the abnormality include problems with the abnormal server itself.

[0136] If it is determined that all business servers are inaccessible, then the cause of the error is determined to be a failure to resolve the business server.

[0137] If all business server IPs are confirmed to be unreachable, the cause of the anomaly is determined to be a DNS resolution failure when the business server resolution fails. If the deep DNS lookup indicates DNS resolution failure, it is recommended that the user switch DNS servers to use as an alternative. If the domain name cannot be resolved, it is recommended to switch DNS servers or contact the network administrator. The system will automatically attempt to retry using an alternative DNS server. The system records the domain name, DNS server IP, and resolution timeout.

[0138] The first step is to determine if the problem lies with your local DNS server. Try resolving the target domain name using a different public DNS server. If the resolution is successful, the local DNS server is faulty, which could be due to the service not running, misconfiguration, or hijacking. If the problem persists, proceed to the next step.

[0139] The second step is to differentiate between network routing issues and authoritative server issues. Obtain the authoritative DNS server for the target domain name and directly query it. If the query succeeds, the authoritative DNS is functioning correctly; however, if the recursive DNS cannot access it, the problem might be a network route interruption between the recursive server and the authoritative server. If the query times out or receives no response, you need to test the reachability of the authoritative DNS's IP address. Test the network connectivity of the authoritative DNS. First, use ping to test the authoritative DNS's IP address. If the ping fails, it's a network routing problem, possibly due to a failure in your local exit point, the ISP's backbone network, or the network where the authoritative server is located. If the ping is reachable but the DNS query still receives no response, the authoritative DNS service itself is faulty.

[0140] The third step is to determine whether the problem lies with the target domain or the server. When the authoritative DNS responds normally to the query, the returned DNS response content needs to be analyzed. If NXDOMAIN is returned, it means the domain does not exist, which may be a domain configuration problem. If SERVFAIL is returned, it means there is an internal error in the authoritative DNS, which is a problem with the authoritative server itself. If the correct IP is returned but subsequent access fails, the resolution is successful, but the target server may be down or the service port may be unavailable. In this case, IP connectivity tests and port tests need to be performed to pinpoint whether the problem is at the network layer or the application layer. Through this layered troubleshooting, combined with deep testing data, the DNS resolution failure can be clearly attributed to the DNS server, network routing, or the target server, allowing for quick implementation of corresponding measures. If the deep testing result indicates a connectivity test failure, the backend records the reason for the failure and presents it to the user for reference and processing; connectivity test failures include ICMP / TCP connectivity test failures, indicating server connection failures, and the backend records the unreachable IP and the reason for the failure.

[0141] The output includes both summary and in-depth results. Summary results include network information, internet connectivity status, and business server connection status. In-depth results include at least a list of DNS servers, domain name connectivity diagnostics, and IP connectivity diagnostics.

[0142] The results are presented in a concise and user-friendly manner, including data on network information, internet connection status, and server connection status. Network information includes Wi-Fi connection status and Wi-Fi authentication status, while server connection status includes the number of successful or failed connections.

[0143] As an example, the depth detection results are easy for the program to parse and are in JSON format.

[0144] The deep testing results include data such as gateway IP, network type, DNS server list, domain connectivity diagnostic results, IP connectivity diagnostic results, and local IP address. Domain connectivity diagnostic results include the domain name, the resolved IP address, and whether it is accessible. IP connectivity diagnostic results include the IP address and whether it is reachable.

[0145] S130. Based on the deep detection results, determine that the network anomaly is caused by the DNS server, the business server, or the network routing.

[0146] If the authentication layer determines that webpage authentication has been completed, the application layer checks whether access to the business server is possible. If access to the business server is not possible, the network anomaly detection process is interrupted.

[0147] Traditional network diagnostic processes typically involve only simple connectivity tests such as ping tests. This application delves into the root causes of network problems. When DNS resolution fails, it differentiates between DNS server issues, network routing problems, and target server issues, providing targeted solutions. A hierarchical diagnostic strategy is designed based on common network problem patterns to improve diagnostic efficiency and quickly pinpoint the problem layer, such as the device layer, connection layer, authentication layer, internet layer, or server layer.

[0148] Different from the network diagnosis result in the prior art that only provides a simple "connection success / failure" status, the present application has detailed diagnostic data and problem location information to assist users in understanding the problematic link. In addition, the obtained in-depth detection result data records detailed technical parameters, which supports problem troubleshooting. In the present application, diagnosis is deeply integrated with service scenarios, and network diagnosis is deeply combined with service scenarios. When a user encounters a network request abnormality, network diagnosis is automatically triggered to help developers quickly determine whether the problem is caused by a network problem. When an H5 page fails to load, network diagnosis is automatically triggered, and the diagnosis result and page load failure information are recorded together, which facilitates subsequent analysis and optimization.

[0149] S130 includes S1301 to S1303:

[0150] S1301: if the connectivity result of the service server is disconnected, determine that the network abnormality is at least caused by the DNS server;

[0151] In some embodiments, the number of service servers is more than one. A service service domain name is subjected to DNS resolution to obtain an IP address corresponding to each server, then attempts are made one by one based on each IP address to obtain the reachability of each IP, so as to test whether it is the IP that is unreachable or the DNS resolution itself that is wrong. If it is determined that all service servers are inaccessible, the abnormal cause lies in the DNS server at the application layer.

[0152] S1302: if the connectivity result of the service servers is partial connectivity, determine that the network abnormality is at least caused by the service server in the service server list;

[0153] IP addresses respectively corresponding to a plurality of service servers are resolved, connectivity detection is sequentially performed on the service server corresponding to each IP address at the application layer in order. If the connectivity result of the service servers is partial connectivity, the service servers that are determined to be unreachable among the plurality of service servers are taken as abnormal servers, and the abnormal cause includes the abnormal servers.

[0154] S1303: if the connectivity result of the service servers is full connectivity, determine that the network abnormality is at least caused by the network route.

[0155] After S130, the method includes S140 to S150:

[0156] S140: if it is determined that the network abnormality is at least caused by the network route, perform detection layer by layer in the order of device layer, link layer, internet layer and authentication layer to obtain a current layer detection result;

[0157] The deployed multi-layered network model includes the device layer, link layer, internet layer, authentication layer, and application layer. It deeply analyzes the root causes of network problems, avoids manual triggering, and automatically triggers layer-by-layer diagnosis. It can detect anomalies in time before the problem escalates, avoid blind testing, accurately locate the level of the problem, and improve the accuracy of network anomaly detection for mobile terminals.

[0158] S140 includes S1401-S1403:

[0159] S1401. If it is determined that the cause of the network anomaly is at least due to the network routing, then obtain the network information of the target mobile terminal at the device layer.

[0160] Device-level network information refers to the current connection status between the device and the network. This information includes the connection type, which indicates the physical or logical channel through which the device accesses the network. Common examples include Wi-Fi, cellular networks, and Ethernet.

[0161] Network information also includes whether it is activated, such as whether the Wi-Fi switch is turned on, whether it is associated with a hotspot, such as being connected to a Wi-Fi network but requiring authentication; and whether it has internet access capability, such as sometimes the device displays "connected to Wi-Fi", but the Wi-Fi itself does not have an external network exit.

[0162] S1402. In response to determining that the link layer is currently connected to the network based on the network information, the connectivity of the Internet layer is detected through a preset public network;

[0163] Based on network information, it is detected whether the link layer is currently connected to the network. If it is determined that the network is not currently connected to the network, the network anomaly detection process is interrupted. The reasons for network anomalies include device-level anomalies.

[0164] Network connectivity assessment is the first step in the network diagnostic process. Before performing any specific network diagnostic operations, it's crucial to confirm that the device possesses basic network connectivity capabilities. If the device is not connected to the network, the diagnostic process should be interrupted, and the user should be guided to check their network connection. This avoids performing invalid diagnostic operations such as DNS resolution and connectivity checks when there is no network connection, wasting system resources, prolonging waiting time, and providing the user with meaningless error messages. Checking whether the link layer is currently connected to the network should be placed at the very beginning of the diagnostic process as a quick filtering condition.

[0165] If it is determined that the current link layer is not connected to the network, the network anomaly detection process is interrupted immediately, stopping all subsequent diagnostic steps. Attempts to obtain the SSID are ceased, and no more probe requests are sent, preventing invalid operations and error messages. A user-friendly and clear message is displayed to the user, such as: "The network anomaly is at the device layer; the device layer is faulty."

[0166] If it is determined that the current link layer is connected to the network, it will continue to try to obtain network information, including SSID address (Service Set Identifier, which refers to the name of the Wi-Fi network) and MAC address (Media Access Control Address, which is the hardware identification of the network device).

[0167] When obtaining the MAC address, a fixed value is returned. Location permissions have been obtained before obtaining the SSID address, and the user needs to enable location services in the system settings.

[0168] The connectivity of the Internet layer is detected through public networks. Network requests are initiated to a set of preset, recognized, stable, and highly available external servers. The success or failure of the requests and the response status determine whether the current device has genuine public network access capabilities.

[0169] A connection to the Internet is considered to be normal if any external endpoint is reachable.

[0170] In some embodiments, a majority consensus principle can be used to improve accuracy. For example, if more than 3 out of 5 probe targets are successful, the network is considered connected. If all endpoints are unreachable, the diagnosis is "no internet connection," and the reason for failure is recorded. Reasons include timeout, connection refusal, DNS failure, etc. In this case, combined with previously obtained network type information, such as Wi-Fi connected but no internet access, specific prompts can be given, for example, Wi-Fi connected but no internet detected, which may require login authentication. The response time for each request is recorded to generate a network quality score. For example, an average response time > 2000ms can be marked as a weak network.

[0171] Ultimately, if it is determined that the Internet layer is not connected, the network anomaly detection process is triggered, indicating that the network anomaly is caused by the Internet layer.

[0172] S1403. In response to detecting the Internet layer connectivity, detect whether the authentication layer has completed webpage authentication.

[0173] If the internet layer connectivity is confirmed, the authentication layer checks whether webpage authentication is complete. A request is sent to a specific URL that is typically not blocked by the local network. By analyzing the response content or status code, it is determined whether the current network has redirected the request to the authentication page. The authentication URL request test usually follows the external URL request test. First, the basic network status is checked to determine if the device is connected to Wi-Fi or cellular. Then, the external URL request test checks whether the internet exit is accessible. If accessible, the authentication layer checks whether webpage authentication is complete. If the authentication test returns a redirect, it is confirmed as a portal authentication scenario. If the authentication test also fails, the network anomaly detection process is interrupted. The cause of the network anomaly includes authentication layer anomalies, specifically network interruption or DNS failure.

[0174] After logging in via the Portal page or clicking "Confirm," and completing the authentication layer test and confirming that the device has passed web page authentication, the diagnostic process will proceed to the application layer test phase. The goal of this phase is to check whether the application's core business server is reachable.

[0175] S150. If the current layer result is abnormal, then the abnormal network route is determined to originate from the current layer.

[0176] If the result of any of the above layers is abnormal, the exception originates from the current layer. As an example, send a lightweight request, such as an HTTP HEAD or a GET request with a timeout, to the business server, such as the application's backend API address, to check if a response can be obtained normally.

[0177] If the expected HTTP status code is received, the request is considered successful, the application layer is considered normal, the diagnostic process continues or ends, and the network status is marked as normal. If the request fails, such as connection timeout, HTTP 5xx error, SSL handshake failure, etc., the diagnostic process ends directly, and the root cause of this network anomaly detection is classified as an application layer anomaly, rather than a network layer problem.

[0178] After S150, including S160-S190:

[0179] S160. Based on the abnormal device layer, a pop-up prompts to enable network data;

[0180] S170. Based on the abnormal link layer, request a refresh of the IP address again;

[0181] S180, Based on an abnormal Internet layer, prompts you to switch networks;

[0182] S190, Based on the exception authentication layer, the page to be authenticated is returned.

[0183] If the network anomaly is determined to be due to a device-level fault, a pop-up window will guide the user to enable network data in system settings. The pop-up will then prompt the user to check if the phone's network switch is turned on and guide them to enable Wi-Fi or cellular data in system settings. After a 3-second delay, the network status will be reacquired. If this fails again, the diagnostic process will terminate, and a network hardware unavailability log will be reported. The device model, system version, and network interface status will be recorded for subsequent analysis to determine if driver or compatibility issues exist.

[0184] If the network anomaly is determined to be caused by a link-layer error, then re-request a DHCP refresh for the IP address. If the device shows it's connected to Wi-Fi but cannot access any external resources, this typically indicates a gateway unreachable or a DHCP allocation error. Displaying "Connected to Wi-Fi, but unable to access the internet," suggestions include trying to restart the router or checking the Wi-Fi password. Also, try calling the system API to re-request a DHCP refresh for the IP address.

[0185] If the network anomaly is determined to be caused by an internet layer failure, prompt the user to switch to cellular network. If the network connection is normal but internet access is unavailable, suggest checking for any outstanding broadband fees. If Wi-Fi is currently available and cellular data is available, prompt the user to switch to cellular network. Record the failed external network address, response time, and error code, and report this to the operations and maintenance platform to assist the operator in locating regional network faults.

[0186] If the network anomaly is determined to be due to an authentication layer failure, the authentication page is displayed to the user. In response to the user's authentication command, the user is redirected to the authentication page. The system displays that the current Wi-Fi requires login authentication and provides an "Authenticate Now" button. Clicking this button opens the browser and redirects to the Portal authentication page. If the authentication page can pop up automatically, the system silently waits for the user to complete authentication and periodically retryes the authentication process. The authentication URL, redirection target, and authentication method (SMS / WeChat / Account) are recorded to optimize the authentication experience.

[0187] If the network anomaly is determined to be caused by an application-layer anomaly, a deep scan is performed, and the results are presented to the user for subsequent anomaly handling. Further deep scans are automatically triggered to obtain more precise causes of failure. The failed domain name, error type (DNS / connection / HTTP), error code, and client IP are packaged and reported to developers for quick identification of whether the problem is server failure, CDN issue, or DNS poisoning.

[0188] This application provides a network detection method, apparatus, and device for mobile terminals. The method includes: responding to a detection command for detecting the network of a target mobile terminal, detecting whether the application layer can access the corresponding service server; responding to the detection that the application layer cannot access the service server, determining a network anomaly, and performing deep detection to obtain deep detection results, the deep detection results including at least a DNS server list, a service server list, and the connectivity results of the service servers; and based on the deep detection results, determining that the network anomaly originates from a DNS server, a service server, or a network route. In this application, anomalies are detected promptly before the problem escalates and its impact expands, avoiding blind manual testing by users. Furthermore, through in-depth analysis and deep detection, the origin of the network anomaly can be distinguished as a DNS server, a service server, or a network route, thus improving the detection accuracy of network anomaly detection for mobile terminals.

[0189] Figure 2 This is a schematic block diagram of a network detection device for a mobile terminal provided in an embodiment of this application. Figure 2 As shown, corresponding to the above-described network detection method for mobile terminals, this application also provides a network detection device 600 for mobile terminals. The network detection method for mobile terminals is applied to the network detection device for mobile terminals. The network detection device 600 for mobile terminals includes a module for performing the above-described network detection of the mobile terminal. A preset network layering model is deployed in the device. The network layering model includes a device layer, a link layer, an internet layer, an authentication layer, and an application layer representing the physical hardware in the mobile terminal. The device is deployed on the target mobile terminal, i.e., the network detection device for the mobile terminal. The network detection device 600 for mobile terminals can be configured in terminals such as desktop computers, tablet computers, and laptops. For details, please refer to... Figure 2 The network detection device 600 for the mobile terminal includes an access detection unit 601, a depth detection unit 602, and a determination unit 603, wherein:

[0190] Access detection unit 601 is used to detect whether the application layer can access the corresponding business server in response to the detection command of the target mobile terminal network.

[0191] The deep detection unit 602 is used to determine a network anomaly in response to detecting that the application layer cannot access the business server, and to perform deep detection to obtain deep detection results. The deep detection results include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers.

[0192] The determining unit 603 is used to determine, based on the deep detection results, whether the network anomaly originates from the DNS server, the service server, or the network routing.

[0193] In some embodiments, the deep detection unit 602, upon detecting that the application layer service server is inaccessible, determines a network anomaly and performs deep detection to obtain a deep detection result, specifically for:

[0194] In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and the IP connectivity result of the business server to the application layer is obtained.

[0195] If all service servers in the IP connectivity results fail to connect, then the DNS server is recorded in the DNS server list, and the connectivity result of the service server is marked as unconnected.

[0196] If some service servers fail to connect in the IP connectivity results, the corresponding service servers that failed to connect are recorded in the service server list, and the connectivity results of the service servers are marked as partially connected.

[0197] If all service servers in the IP connectivity results are successfully connected, then the connectivity result of the service servers is marked as fully connected.

[0198] The deep detection result is obtained by packaging the DNS server list, the business server list, and the connectivity results of the business servers.

[0199] In some embodiments, the determining unit 603, when performing the determination based on the deep detection result to determine whether the network anomaly originates from a DNS server, a service server, or a network route, is specifically used for:

[0200] If the connectivity result of the business server is not connected, then the cause of the network anomaly is determined to be at least the DNS server.

[0201] If the connectivity result of the service server is partial connectivity, then the cause of the network anomaly is determined to be at least one of the service servers in the service server list.

[0202] If the connectivity result of the business server is fully connected, then the cause of the network anomaly is determined to be at least due to the network routing.

[0203] In some embodiments, after determining, based on the deep detection results, whether the network anomaly originates from a DNS server, a service server, or a network route, the determining unit 603 is specifically used for:

[0204] If it is determined that the cause of the network anomaly is at least due to the network routing, then the detection is performed layer by layer in the order of device layer, link layer, Internet layer and authentication layer to obtain the detection result of the current layer;

[0205] If the current layer result is abnormal, then the abnormal network route is determined to originate from the current layer.

[0206] In some embodiments, the determining unit 603, when performing the operation of determining if the network anomaly is determined to originate at least from the network routing, performs layer-by-layer detection in the order of device layer, link layer, Internet layer, and authentication layer to obtain the detection result of the current layer, specifically for:

[0207] If it is determined that the network anomaly is caused by at least the network routing, then obtain the network information of the target mobile terminal at the device layer.

[0208] In response to determining that the link layer is currently connected to the network based on the network information, the connectivity of the Internet layer is detected through a preset public network;

[0209] In response to the detection of Internet layer connectivity, the authentication layer checks whether webpage authentication has been completed.

[0210] In some embodiments, the network detection device of the mobile terminal further includes a feedback unit. If the current layer result is abnormal, the abnormal network route is determined to originate from the current layer. The feedback unit is specifically used for:

[0211] Based on the abnormal device layer, a pop-up prompts to enable network data;

[0212] Based on the abnormal link layer, a new request is made to refresh the IP address;

[0213] Based on an abnormal internet layer, a prompt to switch networks is displayed;

[0214] Based on the exception authentication layer, a page awaiting authentication is returned.

[0215] In some embodiments, the access detection unit 601, in executing a detection instruction in response to the target mobile terminal network, detects whether the application layer can access the corresponding service server, and is further specifically used for:

[0216] In response to a lightweight detection command for detecting a target mobile terminal network, a detection request is initiated to a preset detection point, and the response delay time is recorded. The lightweight detection command is triggered by the application switching from the background to the foreground.

[0217] If the request is successful and the response delay time is within the preset delay range, the network is determined to be normal and the detection is exited.

[0218] If the request is successful and the response delay time exceeds the preset delay range, a weak network prompt is output and the detection is exited. The weak network prompt will not interrupt the user's current operation.

[0219] If the request fails or the response delay exceeds the preset delay range, the current detection result will be displayed and the detection will be exited.

[0220] In some embodiments, before detecting whether the application layer can access the corresponding service server in response to a detection command for detecting the target mobile terminal network, the network detection device for the mobile terminal further includes a trigger signal generation unit, which is specifically used for:

[0221] In response to an application cold start, the application trigger signal unit is specifically used for:

[0222] In response to network type switching, a network state change signal is generated at the corresponding trigger frequency;

[0223] In response to network request errors or page errors, generate an interaction error trigger signal;

[0224] In response to user operation detection data, a manual trigger signal is generated;

[0225] In response to the detection of any one of the application trigger signal, the network status change signal, the interaction anomaly trigger signal, and the manual trigger signal, a detection command for detecting the target mobile terminal network is generated.

[0226] This application provides a network detection method, apparatus, and device for mobile terminals. The method includes: responding to a detection command for detecting the network of a target mobile terminal, detecting whether the application layer can access the corresponding service server; responding to the detection that the application layer cannot access the service server, determining a network anomaly, and performing deep detection to obtain deep detection results, the deep detection results including at least a DNS server list, a service server list, and the connectivity results of the service servers; and based on the deep detection results, determining that the network anomaly originates from a DNS server, a service server, or a network route. In this application, anomalies are detected promptly before the problem escalates and its impact expands, avoiding blind manual testing by users. Furthermore, through in-depth analysis and deep detection, the origin of the network anomaly can be distinguished as a DNS server, a service server, or a network route, thus improving the detection accuracy of network anomaly detection for mobile terminals.

[0227] Specific limitations regarding the network detection device for mobile terminals can be found in the limitations of the network detection method for mobile terminals described above, and will not be repeated here. Each module in the aforementioned network detection device for mobile terminals can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the device in hardware form or independently of it, or stored in the memory of the device in software form, so that the processor can call and execute the corresponding operations of each module.

[0228] In one embodiment, a device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3As shown. The device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a network detection method for a mobile terminal on the server side.

[0229] In one embodiment, a device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 4 As shown, the device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a network detection method for a mobile terminal based on artificial intelligence.

[0230] In one embodiment, an apparatus is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0231] In response to the detection command of the target mobile terminal network, detect whether the application layer can access the corresponding business server;

[0232] In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and a deep detection is performed to obtain the deep detection results, which include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers.

[0233] Based on the deep detection results, it was determined that the network anomaly originated from the DNS server, the business server, or the network routing.

[0234] Therefore, this application also provides a storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the following steps:

[0235] In response to the detection command of the target mobile terminal network, detect whether the application layer can access the corresponding business server;

[0236] In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and a deep detection is performed to obtain the deep detection results, which include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers.

[0237] Based on the deep detection results, it was determined that the network anomaly originated from the DNS server, the business server, or the network routing.

[0238] It should be noted that the functions or steps that the computer-readable storage medium or device can achieve are described in the relevant descriptions of the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0239] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other storage media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0240] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0241] It should be noted that any software tools or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application is authorized (with the knowledge and consent) by the relevant parties or fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0242] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A network detection method for a mobile terminal, characterized in that, The method includes: In response to the detection command of the target mobile terminal network, detect whether the application layer can access the corresponding business server; In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and a deep detection is performed to obtain the deep detection results, which include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers. Based on the deep detection results, it was determined that the network anomaly originated from the DNS server, the business server, or the network routing.

2. The method according to claim 1, characterized in that, In response to the detection that the application layer cannot access the service server, a network anomaly is determined, and deep detection is performed to obtain the deep detection results, including: In response to the detection that the application layer cannot access the business server, a network anomaly is determined, and the IP connectivity result of the business server to the application layer is obtained. If all service servers in the IP connectivity results fail to connect, then the DNS server is recorded in the DNS server list, and the connectivity result of the service server is marked as unconnected. If some service servers fail to connect in the IP connectivity results, the corresponding service servers that failed to connect are recorded in the service server list, and the connectivity results of the service servers are marked as partially connected. If all service servers in the IP connectivity results are successfully connected, then the connectivity result of the service servers is marked as fully connected. The deep detection result is obtained by packaging the DNS server list, the business server list, and the connectivity results of the business servers.

3. The method according to claim 2, characterized in that, Based on the deep detection results, the cause of the network anomaly was determined to be either a DNS server, a service server, or a network route, including: If the connectivity result of the business server is not connected, then the cause of the network anomaly is determined to be at least the DNS server. If the connectivity result of the service server is partial connectivity, then the cause of the network anomaly is determined to be at least one of the service servers in the service server list. If the connectivity result of the business server is fully connected, then the cause of the network anomaly is determined to be at least due to the network routing.

4. The method according to claim 1, characterized in that, Based on the deep detection results, after determining that the network anomaly originated from the DNS server, the service server, or the network routing, the following is included: If it is determined that the cause of the network anomaly is at least due to the network routing, then the detection is performed layer by layer in the order of device layer, link layer, Internet layer and authentication layer to obtain the detection result of the current layer; If the current layer result is abnormal, then the abnormal network route is determined to originate from the current layer.

5. The method according to claim 4, characterized in that, If it is determined that the network anomaly is caused by at least the network routing, then the detection is performed layer by layer in the order of device layer, link layer, Internet layer, and authentication layer to obtain the detection result of the current layer, including: If it is determined that the network anomaly is caused by at least the network routing, then obtain the network information of the target mobile terminal at the device layer. In response to determining that the link layer is currently connected to the network based on the network information, the connectivity of the Internet layer is detected through a preset public network; In response to the detection of Internet layer connectivity, the authentication layer checks whether webpage authentication has been completed.

6. The method according to claim 4, characterized in that, If the current layer result is abnormal, the step of determining that the abnormal network route originates from the current layer further includes: Based on the abnormal device layer, a pop-up prompts to enable network data; Based on the abnormal link layer, a new request is made to refresh the IP address; Based on an abnormal internet layer, a prompt to switch networks is displayed; Based on the exception authentication layer, a page awaiting authentication is returned.

7. The method according to claim 1, characterized in that, In response to a detection command sent to the target mobile terminal network, the method for detecting whether the application layer can access the corresponding service server also includes: In response to a lightweight detection command for detecting a target mobile terminal network, a detection request is initiated to a preset detection point, and the response delay time is recorded. The lightweight detection command is triggered by the application switching from the background to the foreground. If the request is successful and the response delay time is within the preset delay range, the network is determined to be normal and the detection is exited. If the request is successful and the response delay time exceeds the preset delay range, a weak network prompt is output and the detection is exited. The weak network prompt will not interrupt the user's current operation. If the request fails or the response delay exceeds the preset delay range, the current detection result will be displayed and the detection will be exited.

8. The method according to claim 1, characterized in that, In response to a detection command sent to the target mobile terminal network, before detecting whether the application layer can access the corresponding service server, the following steps are included: In response to a cold start of the application, an application trigger signal is generated; In response to network type switching, a network state change signal is generated at the corresponding trigger frequency; In response to network request errors or page errors, generate an interaction error trigger signal; In response to user operation detection data, a manual trigger signal is generated; In response to the detection of any one of the application trigger signal, the network status change signal, the interaction anomaly trigger signal, and the manual trigger signal, a detection command for detecting the target mobile terminal network is generated.

9. A network detection device for a mobile terminal, characterized in that, The device includes: The access detection unit is used to respond to the detection command of the target mobile terminal network and detect whether the application layer can access the corresponding business server. The deep detection unit is used to determine a network anomaly in response to the detection that the application layer cannot access the business server, and to perform deep detection to obtain deep detection results. The deep detection results include at least a list of DNS servers, a list of business servers, and the connectivity results of the business servers. The determining unit is used to determine, based on the deep detection results, whether the network anomaly originates from a DNS server, a business server, or a network route.

10. A network detection device for a mobile terminal, characterized in that, The method includes a memory, a processor, and a network detection program for a mobile terminal stored in the memory and executable on the processor. The processor executes the network detection program for the mobile terminal to implement the steps of the network detection method for the mobile terminal according to any one of claims 1 to 8.

Images