Rabisu VPS Review: Great Specs and Prices, Poor Network Performance

On paper, Rabisu’s Aydın VPS plans look like good value. The x4 plan starts at $2.99 per month and includes 4 GB of RAM; the higher tiers also offer a lot of memory for the price.

Plans and pricing

The monthly prices below are the listed prices on the product page. Annual prices are the totals shown in the order configuration page and exclude payment processing fees. The monthly equivalent is the annual total divided by 12.

At checkout, you can choose an IP address in Türkiye or Bulgaria. Other regions are available at noticeably higher prices. The table below is for the Türkiye - Istanbul region; prices may differ if you select another region.

The listed prices are not the final checkout amounts; a payment processing fee is added. Among the available methods, Alipay and UnionPay had relatively low fees, among the cheapest options.

All of these plans include free backups. The x16 plan also lists a 1 Gbps port, unmetered bandwidth, and a choice of Windows or Linux. Judging only by the specifications and price, these plans look excellent.

My experience

In my tests, the network route was poor and packet loss was noticeable. The IP address also did not appear especially clean. Some of the signals looked mixed, with characteristics of both a data-center IP and a residential IP; I would not make a definitive classification based on what I observed.

Ticket support was surprisingly fast. The provider handled my request soon after I submitted it, which was excellent.

Ping test

These are the results from my local network to the VPS at the time of testing. I have redacted the destination address; the reply times and statistics below are otherwise transcribed from the test:

icmp_seq=47 ttl=40 time=281 ms
icmp_seq=49 ttl=40 time=283 ms
icmp_seq=50 ttl=40 time=273 ms

50 packets transmitted, 39 received, 22% packet loss, time 49356ms
rtt min/avg/max/mdev = 262.626/273.879/289.051/6.661 ms

Traceroute

I have redacted my local gateway, private network addresses, destination IP, and destination hostname. The public forwarding nodes and backbone addresses below are the ones visible in the trace. Each time is a traceroute reply received at the time of testing:

 5  48.254.28.34       41.493 / 41.503 / 41.513 ms
 7  117.135.48.189     46.063 / 42.839 ms  |  117.135.48.157  42.824 ms
 8  221.183.53.225     20.590 ms  |  221.183.53.229  43.912 ms  |  221.183.139.5  39.201 ms
 9  221.183.89.9       40.878 / 45.531 ms
11  221.183.89.173     47.436 ms
12  223.120.6.241      284.053 ms
13  223.120.6.18       200.966 ms  |  223.120.6.70  252.593 ms  |  223.120.2.118  69.776 ms
21  195.219.190.68     348.256 ms
29  [destination redacted]     282.072 ms

Hops 2, 4, 6, 10, 14–20, and 22–28 did not reply. At hop 9, one probe also timed out; hops 11, 12, 21, and 29 returned only some of their probes. Hops 7–11 include nodes in the 117.135.* and 221.183.* ranges, which are associated with China Mobile. At hop 12, 223.120.6.241, the reply time jumps from around 47 ms at the previous hop to 284 ms. The 223.120.* range belongs to China Mobile International (AS58453): 117.135.48.0/24, 221.183.139.0/24, and 223.120.6.0/24.

The three probes at hop 13 received replies from different addresses. IPinfo’s geolocation database roughly places 223.120.6.18 in Los Angeles, 223.120.6.70 in Santa Clara on the US West Coast, and 223.120.2.118 in Hong Kong. These are different replies for the same hop; they do not establish a route that successively passes through all three places. IP geolocation is only an approximation. See IPinfo’s record for 223.120.4.0/22.

The reply at hop 21 took 348 ms, longer than the 282 ms reply from the destination. A traceroute measures ICMP replies from routers, so those values are not a direct measurement of application latency on the VPS. Still, combined with the 22% packet loss in the ping test, the route did not perform well.

This is my Rabisu referral link. I may earn a commission if you purchase through it.