Turkey VDS: What to Check Before You Choose a Provider

A good Turkey VDS gives you low latency to the users you actually serve, CPU and RAM that are really reserved for you, DDoS filtering that works before traffic hits your VM, and a control panel that lets you recover the server without opening a ticket. Check those four areas before you pay, and test each one yourself instead of trusting a feature list.

This guide walks through what to verify and how, with commands you can run on a trial or a fresh server.

1. Location and latency: measure, don't assume

Turkey sits between Europe, the Middle East, and the Caucasus. A server in Turkey makes sense when most of your users are in Turkey or the nearby region, when you need a presence in the country for a specific project, or when you want a second location next to your Frankfurt or US footprint.

It makes less sense if your audience is mostly in North America. Physics sets the minimum round-trip time, and no provider can change that.

Test before you commit

Ask for a test IP or use the provider's looking glass. Then measure from where your users are, not from your own desk.

# Basic latency and loss, 100 packets
ping -c 100 192.0.2.10

# Per-hop view, useful for spotting where latency jumps
mtr -rwzc 100 192.0.2.10

# Path check from the server back to a user network
traceroute -A 198.51.100.50

What to look for:

• Loss at the final hop, not just in the middle. Many routers deprioritize ICMP, so loss in a middle hop that disappears at the last hop is usually harmless.
• Sudden latency jumps that stay high from one hop onward. That points to a long or indirect path.
• Asymmetric routing. Run the test in both directions. The return path can differ from the forward path.

Nixcon runs its own network (AS40368) with its main data center in İzmir, Turkey, and POPs in Frankfurt and Fremont, California. The public looking glass lets you run BGP route, ping, and traceroute queries from İzmir, Frankfurt, and the US before you buy anything.

Check the upstream picture

Ask who the provider is. A provider that operates its own ASN controls its routing and can fix path problems. You can inspect an ASN's announced prefixes and peers with public tools like whois and BGP data sites:

whois -h whois.radb.net AS40368

2. Resource guarantees: what "dedicated" really means

VDS is sold as a virtual dedicated server, but the term has no standard definition. On a hypervisor such as VMware vSphere, the important questions are about reservations and overcommit:

• Is the memory reserved, or can the host balloon or swap it?
• Are vCPUs pinned or reserved, or shared with other VMs under contention?
• Is storage on SSD or NVMe, and are IOPS limited per VM?
• Is the network port shared, and is there a fair-use limit?

Do not accept vague answers. Ask directly, then verify.

Verify CPU contention

Inside the VM, watch the st (steal) column. On some hypervisors steal time is reported only partially, so also watch for high load with low CPU use.

vmstat 1 10
# Look at the "st" column and the "r" (run queue) column

top -b -n 1 | head -5

Consistent steal time above a few percent during normal use is a warning sign. Run the test at peak hours, not at 4 a.m.

Verify disk performance

fio --name=randrw --ioengine=libaio --rw=randrw --bs=4k \
    --iodepth=32 --size=1G --runtime=60 --time_based \
    --direct=1 --filename=/root/fio.test
rm /root/fio.test

Run it several times over a day. Wide swings between runs suggest a noisy neighbor or an IOPS cap.

Verify network throughput

# On the server
iperf3 -s

# From a remote host
iperf3 -c 203.0.113.20 -P 4 -t 30
iperf3 -c 203.0.113.20 -P 4 -t 30 -R   # reverse direction

Test both directions. Compare against the port speed in your plan, and keep in mind that a single TCP stream across a long path rarely fills a fast link.

3. DDoS protection: ask how it works

Almost every host says it has DDoS protection. The details differ a lot, so ask these questions:

1. Where is traffic filtered? At the network edge before it reaches your VM, or only by a firewall on the host?
2. Is it always on or on demand? Always-on is simpler. On-demand mitigation can have a delay while detection triggers.
3. What happens to legitimate traffic? Good mitigation drops attack traffic and leaves normal sessions intact.
4. Does it cover game traffic and UDP? Game servers, VoIP, and custom protocols behave differently from HTTP.
5. Can you see what was blocked? Visibility helps you tune rules and prove what happened.

You also need basic host-level hygiene. Edge filtering does not replace a local firewall. A minimal example with nftables:

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept
nft add rule inet filter input tcp dport 22 accept
nft add rule inet filter input tcp dport { 80, 443 } accept
nft add rule inet filter input icmp type echo-request limit rate 5/second accept

Lock SSH to your own source addresses where you can. If you want to understand what you are defending against, our DDoS protection and firewall page describes the options Nixcon offers on its network.

4. Control panel features that save you at 3 a.m.

A VDS is only as manageable as its panel. When SSH breaks or a kernel update fails, you need out-of-band tools. Check that the panel offers all of these, and test them during your trial period.

Test PTR records

If you plan to send mail, PTR must match your forward DNS. Verify it:

dig -x 192.0.2.10 +short
dig +short mail.example.com A

The two should agree. A mismatch is a common reason for mail being rejected or sent to spam.

Test the restore path before you need it

Do not wait for a disaster to learn how restore works. On a trial server, create a file, take a backup or snapshot, delete the file, and restore. Note how long it takes and whether it restores the whole disk or individual files. Also ask whether backups sit on the same storage as the VM. A backup on the same storage is not a full protection.

Console access and ISO checklist

• Can you mount a custom ISO yourself, or must you ask support?
• Does the console work on a freshly booted VM, including the BIOS or boot menu?
• Can you boot a rescue ISO and mount the disk?
• Is the console usable from a browser without special plugins?

5. Extra things to check

• IPv6. Ask for a routed prefix and confirm you can set reverse DNS for it. Documentation examples use 2001:db8::/32, but you will receive a real allocation.
• Operating system choice. Check that the templates you want are available and kept up to date.
• Support access. Know how to reach engineers and in which language.
• BGP needs. If you own an ASN and IP block, ask whether you can announce them from the VDS. Nixcon offers BGP-enabled VDS on VMware vSphere, with options for unprotected or DDoS-protected announcements and for a full routing table. Ownership of the ASN and prefix is validated automatically through RPKI ROA and RIR/IRR records.
• Legal and compliance. If you serve users in Turkey or host data there, check which local rules apply to your project and get qualified advice. A hosting provider cannot do this for you.

Common mistakes and fixes

Choosing by price per core alone. A cheaper plan with heavy CPU contention can cost more in lost time. Fix: run the steal and disk tests at peak hours.

Testing latency from one location. One ping from your office says little. Fix: use a looking glass and test from several networks.

Assuming DDoS protection covers everything. Edge filtering does not patch a vulnerable application. Fix: keep software updated and use a host firewall.

Skipping the restore test. Many people discover backup limits during an incident. Fix: test restore during the trial.

Forgetting PTR. Mail setups fail on reverse DNS more often than on SPF. Fix: set and verify PTR on day one.

Quick pre-purchase checklist

1. Run ping and mtr from your user regions.
2. Ask what is reserved: CPU, RAM, disk IOPS, bandwidth.
3. Check vmstat steal and fio results over a day.
4. Confirm how DDoS filtering works and what traffic types it covers.
5. Test console, ISO mount, reinstall, PTR, and restore.
6. Confirm IPv6 and, if needed, BGP support.

Spend an hour on these checks and you will know much more than any product page can tell you.