Global service status page [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Hello Support Engineer A,
Thank you for confirming the CU backbone congestion shown in the attached MTR reports.
During the initial period when my bandwidth usage was still within the 10% refund-eligibility limit, the network performance was materially better and did not exhibit the current sustained degradation. The serious and recurring congestion became apparent only after my usage exceeded that threshold.
Therefore, I could not reasonably identify this persistent service-quality issue while I was still within the refund limit. I purchased and continued using the service based on its performance during that initial period, but the service subsequently delivered has been substantially different.
My refund request therefore remains unchanged. Please review the circumstances and process the refund as soon as possible.
Thank you.
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer A || Staff
Hello,
In the attached mtr report the CU backbone congestion is visible. Regretfully there is not much we can do about this; CU has to upgrade their network. They are aware of this issue.
Thank you.
Support Engineer A
Bandwagon Host / IT7 Networks
Global service status page [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
For easier review, I have separately attached the most severely affected 100-cycle MTR report from the continuous monitoring dataset. It was captured at 23:50 China Standard Time on August 11, 2026 (15:50 UTC). From B to [VPS IPv4 REDACTED], it recorded 3 destination packet losses out of 100 probes (3%), an average latency of 193.3 ms, and a maximum latency of 213.3 ms.
This is the clearest and most severely affected individual sample from the incident period. I have also provided the complete continuous dataset covering 23 consecutive time windows and 46 bidirectional 100-cycle reports. Those continuous reports demonstrate that the problem persisted and that this individual report was not selectively cherry-picked as an isolated anomaly.
Please review this sample together with the complete continuous evidence. The trans-Pacific latency degradation and destination packet loss remain present after the routing adjustment.
Based on my actual usage experience, the network degradation was even more severe at approximately 17:00 China Standard Time yesterday.Unfortunately, MTR monitoring was not running at that time.
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Hello, after your routing adjustment, I continued bidirectional MTR monitoring. The attachment contains 46 bidirectional 100-cycle reports across 23 consecutive time windows. Both directions show sustained latency degradation, and each direction recorded 10 destination packet losses out of 2,300 probes. The hop-by-hop results indicate that the degradation appears to begin on the trans-Pacific segment, around the handoff between [PREMIUM BACKBONE RANGE REDACTED] and [INTERCONNECTION RANGE REDACTED]. This is not an isolated event and confirms that the issue remains after the adjustment.
My service will enter its second billing month tomorrow. Please review and process my refund request as soon as possible to avoid any dispute regarding the start of a new billing cycle. Since the service still does not meet the expected network quality, I am requesting a refund before the next billing period begins.
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer A || Staff
Hello,
Thank you for the provided mtr reports.
It looks like some segments of China Unicom's premium network have been congested during peak hours. We have made an adjustment on our side to help route around the congestion and will be monitoring it.
Support Engineer A
Bandwagon Host / IT7 Networks
Global service status page [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Agent D || Staff
Hello,
Our team is working on your ticket, please allow us some time to get back to you.
Thank you.
Support Agent D
Bandwagon Host / IT7 Networks
Global service status page [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
AS FOLLOWS
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Bidirectional MTR reports collected during this evening’s peak hours.
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
My Ip is: [CLIENT PUBLIC IPv4 REDACTED]
If you need to perform testing, I only authorize ICMP or TCP MTR tests.
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Just as follows
Please do not disclose my IP address. If you need to perform testing, I only authorize ICMP or TCP MTR tests. Please do not test it from a large number of different IP addresses or launch any DDoS attacks against it. This IP is under strict access control and monitoring.
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer A || Staff
Hello,
For further networking review, please share:
1) 100-cycle mtr report from your location to [VPS IPv4 REDACTED]
2) Reverse 100-cycle mtr report (from [VPS IPv4 REDACTED] to your IP)
3) IMPORTANT: please share just 1) and 2) and *nothing else* (no LLM interpretation etc).
Thank you.
Support Engineer A
Bandwagon Host / IT7 Networks
Global service status page [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer B || Staff
Hello,
Thank you for the detailed follow-up and for the Tencent Cloud measurement data.
Looking at your Tencent Cloud results together with the reverse monitoring data, the pattern (elevated latency and intermittent packet loss specific to Beijing China Unicom, while nearby regions on the same carrier such as Tianjin perform noticeably better) is consistent with a regional routing issue within the China Unicom network, rather than a general problem with the datacenter or the route as a whole.
From the tools available to us, I cannot investigate that specific regional segment in more depth. I am therefore relaying this ticket to a more senior network engineer for an in-depth review of the Beijing China Unicom route towards USCA_9, and to determine whether there is anything we can do about it from our side. Please keep in mind that if the issue is located within the carrier's own regional network, our options may be limited, but we will review it properly before drawing any conclusion.
Please note that this review may take some time to complete. We will update this ticket as soon as I have the results.
I have also noted your comments regarding the refund request and will include them with this escalation.
Best regards,
Support Engineer B
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Subject: Beijing China Unicom Issue Remains Unresolved — Request for Senior Network and Billing Review
Hello Support Engineer B,
Thank you for your reply. However, I must be very clear: my complaint has repeatedly and specifically concerned the extremely poor experience from Beijing China Unicom. I cannot identify any Beijing China Unicom probe in the ping.pe snapshot you supplied. If such a probe is present, please identify its exact location and carrier explicitly.
A clean result obtained from other cities or other carriers does not establish that the Beijing China Unicom route is healthy. Presenting a snapshot that does not test the specific region and carrier being reported, and then drawing the blanket conclusion that “the path currently looks clean,” is not a technically valid response to my complaint. It gives the appearance of dismissing a narrowly defined routing problem without actually measuring it.
The newly attached results are not from itdog.cn. They were collected through Tencent Cloud’s official Cloud Dial Testing and Observability platform against this VPS at [VPS IPv4 REDACTED].
Please review the attachments carefully:
Attachment 1 shows the measurements sorted from lowest to highest latency. Tianjin China Unicom was approximately 141 ms.
Attachment 2 shows the same target sorted from highest to lowest latency. Beijing China Unicom repeatedly measured approximately 162–211 ms, with individual observations reporting packet loss of up to 15%.
Beijing and Tianjin are geographically adjacent, yet the China Unicom results differ by as much as approximately 70 ms. More importantly, the Beijing results are both materially higher and substantially more variable. This difference should not be dismissed without an actual Beijing China Unicom route investigation.
Attachment 3 contains today’s continuous reverse-monitoring results from the VPS towards Chinese probes. Beijing China Unicom averaged approximately 184 ms with 3.1% packet loss, again performing materially worse than the other probes shown on the same page.
Attachment 4 confirms that this monitoring instance corresponds to the affected VPS at [VPS IPv4 REDACTED].
These measurements were collected on August 8, after the August 5 incident that you stated had already been resolved. Therefore, the present evidence cannot be explained merely by the brief August 5 period mentioned in your reply.
I understand that reverse monitoring is not identical to a client-side MTR, but it is independent corroborating evidence of a carrier- and region-specific problem. Combined with the Tencent Cloud Beijing China Unicom measurements, it demonstrates that the issue is real and remains relevant to my actual usage.
I am currently travelling for work and have already spent a disproportionate amount of time repeatedly proving the same issue. If required, I can provide the raw Tencent Cloud probe data. However, if Tencent Cloud’s official probe data is also to be rejected merely because it was not generated by your own platform, then you should provide an actual Beijing China Unicom probe or another technically valid way to examine the exact route I have reported. A test that omits Beijing China Unicom cannot rebut a complaint about Beijing China Unicom.
Regarding the refund request, I do not accept “technically impossible in our billing system” as a sufficient final answer. A limitation of the standard billing interface is an internal operational limitation; it does not necessarily mean that an authorised billing manager cannot approve or process an exceptional manual adjustment.
I am not requesting an unjustified full refund or attempting to avoid paying for the period already used. As previously explained, I am requesting that the used period be charged at the ordinary, non-discounted equivalent rate and that the unused portion be refunded to the original payment method. This is a discretionary service-quality request, not an automatic refund request under the standard bandwidth-usage policy.
The network performed well when I initially purchased and began using the service. Its subsequent deterioration is precisely the reason for this request. Experiencing good performance initially and then being left with materially degraded service for the remainder of a prepaid term is particularly frustrating. Since the service no longer provides an experience comparable to what I received at the beginning, I believe a proportional refund of the unused service period is reasonable.
I acknowledge the offer to migrate to DC6, but I do not accept migration as an adequate resolution. It would change my IP address, does not address the unresolved USCA_9/Beijing China Unicom problem, and provides no assurance that the same deterioration will not occur again. I selected and paid for this service based on its original performance, not on the assumption that I would later need to relocate it to another datacenter.
Please escalate this ticket to:
A senior network engineer who can review the Beijing China Unicom route specifically, including its evening-peak behaviour; and
A billing supervisor authorised to review discretionary refunds outside the automatic eligibility system.
Please address the following points directly:
Does your ping.pe snapshot contain a Beijing China Unicom probe? If so, which exact probe is it?
How do you explain the August 8 Tencent Cloud measurements showing repeated 162–211 ms Beijing China Unicom latency and reported loss?
How do you explain the reverse-monitoring result showing approximately 184 ms and 3.1% loss for Beijing China Unicom?
Has the Beijing China Unicom path towards AS10099/9929 been examined specifically during China’s evening peak?
Has my refund request been reviewed by someone authorised to approve a manual exception, rather than only checked against the automated refund rules?
If you still conclude that there is no Beijing China Unicom problem, please provide a Beijing China Unicom-specific technical explanation rather than another general snapshot from unrelated locations.
The attached measurements contain operational and network information shared with you in confidence for support purposes. Please do not redistribute or use them for unrelated purposes.
I look forward to a substantive technical and billing review.
Best regards,
[CLIENT]
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer B || Staff
Hello,
Thank you for the additional tests and the detailed explanation.
Please note that we cannot accept measurements from third-party testing services such as itdog.cn, as we have no control over their probes or methodology. For network diagnostics we rely on our own ping.pe service, which also supports creating verifiable snapshots, or the mtr reports performed from the your own devices.
Here is a fresh ping.pe snapshot to your VPS IP, and the path currently looks clean:
[[TEST SNAPSHOT LINK REDACTED]]([TEST SNAPSHOT LINK REDACTED])
In addition, we run extensive continuous monitoring of our routes. For USCA_9 towards the China Unicom network inside China, our monitoring does not show any performance degradation, with the exception of a brief period on 2026-08-05 between 07:00 and 11:00 UTC inside China Unicom network, which has since been resolved.
Regarding the refund: unfortunately, partial/prorated refunds are not technically possible in our billing system, so we are unable to offer one, and the same applies to prorated account credit.
However, since you mentioned that DC6 performs well from your location, you are welcome to migrate your VPS to another datacenter free of charge. This can be done directly from KiwiVM ("Migrate to another DC"). Your data is preserved during migration, but please note that the IP address of the VPS will change.
Please let me know if you have any other questions.
Best regards,
Support Engineer B
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
> Hello Support Engineer B,
>
> I would also like to add some important context regarding the recent service quality.
>
> The network performance of this VPS was previously quite good, which was one of the reasons I continued using the service. However, during the past two days, the China Unicom experience has deteriorated sharply. During the evening peak period, the average latency can exceed **200 ms**, together with noticeable packet loss, jitter and connection instability.
>
> I have also seen other recent user reports and public monitoring results describing a similar deterioration. Based on the observed route, this may be related to a recent AS9929 backbone or interconnection problem. However, I cannot conclusively identify the responsible network segment from the user side, which is why I hope your network team can investigate it.
>
> I deliberately chose Bandwagon Host despite its premium price compared with many competing providers because I expected correspondingly better routing quality, stability and technical support. I was willing to pay this premium specifically to obtain a dependable connection for latency-sensitive work. Unfortunately, under the current conditions, that expectation has not been met.
>
> This is especially problematic during the midday and evening peak periods, when the connection is most important for my real-time trading-related workload. An average latency above 200 ms, combined with packet loss and jitter, can delay market-data delivery and order acknowledgements, interrupt persistent connections, and materially reduce the practical value of the service.
>
> I understand that temporary backbone incidents can occur. Nevertheless, because the deterioration has been both sudden and severe, I would appreciate it if your network team could confirm whether there is a known AS9929 or related interconnection issue, and whether any corrective action or routing adjustment is possible. If the expected network quality cannot be restored, I respectfully ask that my previously submitted discretionary prorated refund request continue to be considered.
>
> Best regards,
> [CLIENT]
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Subject: Additional Beijing China Unicom MTR Evidence and Peak-Hour Impact
Hello Support Engineer B,
I apologize for the delayed response. I am currently travelling and therefore saw your reply later than expected.
I would also like to clarify that my previous test was conducted while I was temporarily staying in another city under relatively poor local network conditions. My primary place of work is Beijing. To remove the influence of that temporary access environment, I performed additional tests using the public Beijing China Unicom probes provided by ITDOG.
I have attached the complete original screenshot generated by ITDOG. The public test address is:
[[PUBLIC TEST LINK REDACTED]]([PUBLIC TEST LINK REDACTED])
The attached representative result was obtained from the "Beijing 3 - China Unicom" public probe. Its relevant responding hops were:
- Beijing China Unicom AS4808: 0% loss
- China Unicom AS4837, [CHINA UNICOM BACKBONE HOP REDACTED]: 0% loss
- AS9929, [PREMIUM BACKBONE HOP REDACTED]: approximately 4% loss
- Following AS10099, [INTERCONNECTION HOP REDACTED]: approximately 4% loss
- Final destination: approximately 7% end-to-end ICMP loss
I understand how the 100% values in an MTR report must be interpreted. Hops 4-6 and 12-17 do not answer TTL-expired ICMP probes, while later hops and the destination still respond. Therefore, those 100% entries are non-responding or ICMP-filtered intermediate routers, not evidence of 100% forwarding loss. Similarly, the isolated 97% and 18% values are not being used by themselves as proof, because an intermediate router may rate-limit ICMP responses.
The 4% and 7% values also should not be added together or treated as two independent losses. The approximately 4% shown on two consecutive responding hops means that a lower loss state remained visible from the later AS9929 hop into the following AS10099 hop. The 7% shown at the final destination is the end-to-end ICMP loss observed by the Beijing public probe during that test. It indicates that the complete route was not better by the time traffic reached the destination, but it does not by itself prove that the destination server originated all of the loss. The important point is that a persistent abnormality was already visible before the destination, after the stable AS4808 and AS4837 portion of the route.
This pattern is therefore more consistent with degradation around the later AS9929-to-AS10099 transmission or interconnection section than with my temporary local access network. I am not attempting to identify one specific defective router solely from ICMP data; I am asking that the relevant route section be reviewed by the network team.
I also repeated the public-probe test several times using two independent Beijing China Unicom probes. Across six runs, all six showed non-zero destination loss. The combined weighted destination loss was approximately 4.77%, with a weighted average latency of approximately 181 ms. This supports that the attached result was not selected from a single isolated failure.
From my actual usage observations, the problem becomes especially severe and repeatedly reproducible during the Beijing midday peak period and evening peak period. During quieter periods the route can appear substantially better, so a single off-peak test may not reproduce the real service impact. During peak periods I experience noticeably worse packet loss, latency jitter and connection instability.
This has a material effect on my primary workload because I use the connection for latency-sensitive, real-time trading-related work. Packet loss and latency jitter can delay market-data updates, order submissions and acknowledgement messages, interrupt persistent WebSocket sessions, and trigger reconnections. Even short interruptions can result in stale market information, delayed execution or additional slippage. Stable and predictable packet delivery is therefore essential to my work, rather than merely high peak bandwidth.
Could you please ask the network team to review the AS9929/AS10099 portion of this route, particularly during Beijing midday and evening peak hours, and include the attached evidence in the ongoing discretionary prorated refund review?
Best regards,
[CLIENT]
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Engineer B || Staff
Hello,
Thank you for the detailed reports.
According to the MTR reports you've provided, the problem appears to be between the [CLIENT FIRST-HOP IPv4 REDACTED] and [REGIONAL ISP HOP REDACTED] hops.
This is evident from the significantly elevated Worst and StDev values, and from the fact that they propagate through all the remaining hops.
This doesn't look like regular ICMP dropping by intermediate routers, but rather indicates a problem in the first leg of the route.
If that is your regional ISP, I would recommend contacting them and providing these MTR reports.
From our experience, clean MTR reports should not look like this for the part of the route within China.
Please let me know if you have any other questions.
Best regards,
Support Engineer B
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Agent C || Staff
Hello [CLIENT],
Thank you for the additional context. I understand that you are asking for a review of the China Unicom performance specifically for USCA_9, including comparison against USCA_6 routing/return-path behavior for northern China Unicom users.
This VPS is in US: Los Angeles, California (DC9 AMD+NVMe, CT CN2GIA-E, CMIN2, CUP) (USCA_9), and the earlier MTR target matches this VPS at [VPS IPv4 REDACTED]. I am keeping this ticket in the correct queue so the network-related evidence and your request for a discretionary prorated refund to the original payment method can be reviewed together.
Please do not terminate the VPS yet if you still need the data or want the review completed before cancellation. I cannot confirm any refund amount before that review is completed.
Support Agent C
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
Thank you for escalating this case to the appropriate team. I would like to add some further context for the network review.
As an end user, I cannot conclusively determine whether the high latency is introduced within my local China Unicom access/aggregation network or during the handoff toward the first visible AS4837 hop, because hops 2 and 3 do not respond to ICMP. Therefore, I do not want to overstate the exact fault location.
However, there are several pieces of evidence suggesting that the poor experience is not limited to a single isolated local test:
1. In the 100-cycle MTR I previously submitted, my first hop remained stable, while severe latency spikes and timeouts continued through to the destination at [VPS IPv4 REDACTED].
2. I also previously provided the reverse monitoring results from this VPS to a Beijing China Unicom endpoint. Although this is a different direction and should be treated as supplementary evidence, it likewise shows repeated latency spikes and a peak of several seconds. Please refer to the files already attached to this ticket.
3. The public latency monitoring available on DigVPS for the USCA_9 location also shows that Beijing China Unicom latency has risen rapidly recently:
[https://digvps.com/review/bandwagon](https://digvps.com/review/bandwagon)
This third-party monitoring is not intended as proof for my specific VPS, but it provides independent product/location-level corroboration.
4. I am personally located within the northern China Unicom service region, where the practical experience with DC9 has been genuinely poor, including intermittent high latency, stalls, and periods when normal use becomes very difficult. What is particularly confusing is that DC6 can remain smooth for northern China Unicom users, while DC9 performs very poorly under otherwise similar access conditions.
Could your network team please compare the China Unicom routing, handoff, capacity, and return-path behaviour between DC6 and DC9, especially for northern China Unicom users?
I understand that no single measurement can conclusively identify the responsible router. Nevertheless, the combination of my forward MTR, the previously supplied reverse monitoring, my actual usage experience, and the independent DigVPS latency history all point to a persistent service-quality problem affecting DC9 for northern China Unicom users.
I would appreciate it if your team could review whether the routing can be corrected. If it cannot be corrected, please continue considering my previously stated request for a discretionary prorated refund to the original payment method. As mentioned before, I am not requesting a full refund.
Thank you for your time and careful review.
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Agent C || Staff
Hello [CLIENT],
Thank you for providing the new 100-cycle MTR evidence. The test target now matches this VPS at [VPS IPv4 REDACTED], and the summary you provided shows loss/latency spikes continuing through to the destination, so this is usable for network review.
I also understand that your refund request is specifically for a discretionary prorated refund to the original payment method if the routing issue cannot be corrected. The standard automatic refund check still shows this VPS is not eligible because bandwidth usage is above the refund eligibility threshold, so I cannot confirm a refund amount from here.
I am moving this ticket to the correct queue so our team can review both the China Unicom routing evidence and the discretionary refund request. Please do not terminate the VPS yet if you still need to back up your data or if you want the service reviewed before cancellation.
Support Agent C
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
————————
[EXACT TICKET TIMESTAMP REDACTED] [CLIENT] || Client
Subject: China Unicom routing issue - 100-cycle MTR evidence for [VPS IPv4 REDACTED]
Hello Support Agent C,
Thank you for your reply. After receiving your message, I restarted my computer and immediately ran a new 100-cycle, timestamped MTR-style test from the affected China Unicom connection to [VPS IPv4 REDACTED]. The ICMP test traffic followed the direct network route rather than a proxy tunnel. I have attached both the human-readable summary and the complete raw results.
I have also included same-day reverse-direction monitoring from the VPS to a Beijing China Unicom endpoint as supplementary evidence. As stated in that report, it does not replace the requested forward-direction test.
My local connection is over Wi-Fi, so I acknowledge that it may introduce some variation. However, the first hop ([CLIENT FIRST-HOP IPv4 REDACTED]) recorded 0% packet loss, an average of 5.01 ms, and a maximum of 47.18 ms over all 100 cycles.
More importantly, during the clearest degraded interval (cycles 33-42), the first hop remained between 2.65 ms and 4.58 ms, while the destination timed out three times and successful destination replies repeatedly reached 559-1,485 ms.
Relevant forward-path results:
- Hop 8, [CHINA UNICOM BACKBONE HOP REDACTED]: 3% loss, 246.62 ms average, 1,348.77 ms maximum
- Hop 9, [PREMIUM BACKBONE HOP REDACTED]: 3% loss, 251.78 ms average, 1,355.56 ms maximum
- Hop 10, [PREMIUM BACKBONE HOP REDACTED]: 3% loss, 251.97 ms average, 1,355.54 ms maximum
- Hop 11, [INTERCONNECTION HOP REDACTED]: 3% loss, 384.56 ms average, 1,486.51 ms maximum
- Destination, [VPS IPv4 REDACTED]: 3% loss, 382.12 ms average, 1,485.00 ms maximum
The severe latency spikes are already clearly visible by hop 8 and continue through hop 11 to the destination, while the first hop remains stable during the affected interval. I understand that an MTR result alone cannot conclusively identify the responsible carrier or device, but these measurements show that the observed multi-second instability is not explained by the local first hop.
The supplementary reverse-direction report covers 2026-08-06 05:22:12 to 16:24:37 CST and contains 6,530 TCP probes in 653 groups. It independently shows pronounced latency variation, including a 5,668.6 ms single-probe peak.
Please note that these attachments contain potentially sensitive network, routing, and IP-address information. I am sharing them with your team in good faith and because I trust BandwagonHost to use them solely for investigating this support request.
Please treat this information as confidential and restrict access to personnel involved in troubleshooting. I respectfully request that the files and IP-related information not be published, redistributed, disclosed to unrelated third parties, used for marketing, or sold as data.
Could you please review the attached evidence and check whether there is a routing or circuit issue affecting China Unicom traffic?
My refund request remains unchanged. I am not requesting a full refund. If the routing problem cannot be corrected, I would appreciate a prorated refund covering only the unused portion of the service term. I am willing for the first month already used to be charged at the regular, undiscounted rate.
If the refund is approved, please return it to the original payment account or payment method used for this purchase rather than issuing account credit.
Thank you for your time and assistance.
Best regards,
Attachments:
[[ATTACHMENT NAME REDACTED]]([PRIVATE ATTACHMENT LINK REDACTED])
————————
[EXACT TICKET TIMESTAMP REDACTED] Support Agent C || Staff
Hello [CLIENT],
I understand the connection quality issue is frustrating.
I checked this VPS, and it is not eligible for the standard automatic refund because bandwidth usage is above the refund eligibility threshold. Because of that, I cannot confirm an automatic prorated refund, account credit, or refundable amount from here.
Since you are asking for a discretionary exception, I am moving this ticket to the correct queue for review. Please do not terminate the VPS yet if you still need to back up your data.
For the network-performance part, the attached screenshot does not show a visible destination IP/hostname, so it cannot be matched to this VPS. If you would like the route reviewed as well, please provide a 100-cycle MTR from the affected China Unicom location to [VPS IPv4 REDACTED] during the issue.
Support Agent C
Bandwagon Host / IT7 Networks
Global service status page: [https://bwhstatus.com/](https://bwhstatus.com/)
Diagnose network-related issues at [https://ping.pe/](https://ping.pe/)
I purchased the [SERVICE PLAN REDACTED] service in USCA_9 on [PURCHASE DATE REDACTED], for [PURCHASE AMOUNT REDACTED] on a semi-annual billing cycle.
Unfortunately, the actual network performance has not met my expectations. In particular, the connection quality through China Unicom has been extremely poor over the past two days, and the service has become difficult to use reliably for my intended purpose.
I understand that my bandwidth usage exceeds the threshold of the standard 30-day refund policy, so I am not requesting an automatic full refund. However, since I prepaid for six months, would you please consider a discretionary prorated refund, or alternatively an account credit, for the unused portion of the remaining term?
I am willing to have the first month charged at the regular, non-discounted monthly rate, with the remaining unused amount refunded or credited.
Please confirm whether this arrangement is possible and advise me of the refundable or creditable amount before terminating the service. I will back up my data and authorize cancellation after receiving your confirmation.
快乐的出帆 08-12 19:431楼
reidme 08-12 19:452楼
LocalGhost 08-12 19:463楼
Nonebody 08-12 19:506楼
KEVI 08-12 19:527楼
licong 08-12 19:578楼
流川 08-12 20:2510楼
a5410109 08-12 21:1611楼
lampardcharis 08-12 22:4512楼
anarkh35 08-12 22:5813楼