Overview
I was looking for a travel router that I could use while working away from home to securely connect to my work network, route devices such as my phone and laptop through a secure network tunnel, reduce my footprint on the local network, and keep my devices isolated from other clients on that network. After considering features such as OpenWrt and VPN support, I decided to go with the Cudy TR1200.
The Cudy TR1200 stands out with its affordable price while offering all of the operating modes I would expect from a travel router, including Router/AP, WISP/Extender, and Client modes. It also supports features such as Cudy Mesh with multiple Cudy routers, captive portal, native router-level VPN support, DNS over TLS, Samba/SMB file sharing over USB 2.0, the ability to reconfigure the WAN port as a LAN port when needed, and a physical VPN switch. Overall, it covers not only the basic requirements of a travel router but also many features I would normally expect from more advanced models.
Hardware and Technical Specifications
| Category | Specification | Value |
|---|---|---|
| Model | Model Version | TR1200 1.0 |
| Hardware | CPU | 580 MHz Single-Core, MIPS24KEC |
| Flash / ROM | 16 MB (128 Mbit) NOR | |
| DDR / RAM | 128 MB (1 Gbit) DDR3 | |
| Wireless | 5 GHz Wi-Fi Speed | 867 Mbps |
| 2.4 GHz Wi-Fi Speed | 300 Mbps | |
| Interfaces | Ethernet Ports | 2× 10/100 Mbps RJ45 |
| Ethernet Layout | 1× WAN, 1× LAN | |
| USB | 1× USB-A 2.0 | |
| LED | System | |
| Physical Controls | Reset Button, Configurable DIP Switch | |
| VPN Throughput | WireGuard Client | 49 Mbps Upload / 43 Mbps Download |
| WireGuard Server | 43.6 Mbps Upload / 48 Mbps Download | |
| Power | Power Input | USB-C |
| Power Options | USB-C, PD | |
| Input Rating | 5V ⎓ 2A | |
| Maximum Power Consumption | 8 W | |
| Idle Power Consumption | 3 W |
Design and Physical Layout
One of the main reasons I chose the TR1200 was that I wanted a small and lightweight NAT/VPN router that I could simply throw into my bag alongside my Mac and forget that it was there. At approximately 100 grams and 4.65 × 3.15 × 1.08 inches, the TR1200 strikes a good balance between portability and functionality.
There are two foldable external antennas, one on each side of the device. On the rear, there is one USB-A 2.0 port, one 10/100 Mbps LAN port, one 10/100 Mbps WAN port, and a USB-C power input. Storage devices connected to the USB port can be shared over the network using Samba/SMB. In supported operating modes, the WAN port can also be reconfigured and used as an additional LAN port.
Cudy rates the maximum power consumption at 8 W under load, including the USB port, while idle consumption is listed at approximately 3 W. The router can be powered using 5V/2A or USB Power Delivery. Since it uses USB-C for power, I can run it from a compatible laptop or phone charger, or even a power bank, without carrying a dedicated power adapter.
The device also includes a reset button and a configurable physical switch. Using the stock firmware, I can configure this switch to enable or disable the VPN. Since integrated VPN functionality has effectively become a standard feature in travel routers, being able to control it with a physical switch is a nice addition at this price point.
On the front of the router, a single System LED indicates different operating states. Instead of using several separate activity LEDs, Cudy uses a single indicator for the overall router status, which I also find to be a nice design choice.
| System LED | State | Meaning |
|---|---|---|
| 🔴 Red | Blinking | System is booting |
| 🔴 Red | Solid | System is running but there is no internet connection |
| ⚪ White | Blinking | Internet/upstream connection is being established |
| ⚪ White | Solid | Internet connection established |
| Off | — | Device is powered off |
Management and Initial Setup
The router can be managed either through the cloud-based Cudy App or through the web interface available on the router's local network. I did not want to install another Android application just to configure the router, so I continued with the web interface.
For the initial setup, I connected an Ethernet cable from my upstream internet router to the WAN port on the TR1200. I then connected the TR1200's LAN port to my laptop using another Ethernet cable.
By default, the TR1200 uses the 192.168.10.0/24 subnet with 192.168.10.1 as its gateway address. The web interface is also available at 192.168.10.1.
After connecting the cables and opening this address in my browser, I was first prompted to create an administrator password. Once that was done, the router redirected me to the Quick Setup wizard. There are five different setup options available. Since I wanted to create a separate LAN behind NAT, I continued with Wireless Router mode.
The following screens allowed me to configure the timezone and WAN settings. The WAN configuration page provides options such as PPPoE, Static, and Dynamic (DHCP). Since DHCP was already enabled on my upstream router and it could automatically assign an IP address to the TR1200 over Ethernet, I selected Dynamic (DHCP).
When configuring the WAN side, it is important to make sure that the upstream and downstream router subnets use different IP ranges. Overlapping WAN and LAN subnets can introduce routing ambiguity and cause connectivity problems.
After completing the WAN configuration, I moved on to the wireless settings. Here, I configured separate SSIDs, passwords, and wireless encryption settings for the 2.4 GHz and 5 GHz bands.
Once the setup was complete, the router rebooted. The System LED turned solid white, and I also confirmed through the web interface that the upstream connection had been successfully established.
Performance Tests and Limitations
There were two major limitations I was already aware of when purchasing the TR1200.
First, both the WAN and LAN ports are rated at 100 Mbps in the official product documentation, and real-world throughput remains somewhat below that value. I also observed occasional fluctuations in wired performance.
The second limitation is WireGuard performance. According to Cudy's published figures, WireGuard throughput falls into roughly the 43–49 Mbps range.
Despite these limitations, considering the router's price and intended use case, I still find the performance sufficient for everyday use and think the TR1200 fits well into the price-to-performance segment.
I spent a weekend exploring the limits of the device and ran four different test scenarios across two router modes. For the tests, I used two separate PCs and an older OpenWrt router with Gigabit Ethernet and 2.4 GHz Wi-Fi as the upstream WAN network.
Test Methodology
For each test case, I ran two different iperf3 tests between a server and a client.
- I generated a 50 Mbit/s UDP load between the server and client for 60 seconds and monitored packet loss and jitter.
iperf3 -c xxx.xxx.xxx.xxx -u -b 50M -t 60 -i 2
- I opened four parallel TCP streams between the server and client and generated traffic for 60 seconds. I used the individual throughput values of the four streams together with their aggregate throughput to observe the total TCP throughput achievable across the tested path.
iperf3 -c xxx.xxx.xxx.xxx -P 4 -t 60 -i 2
Test Environment
Upstream OpenWrt WAN Router
Wi-Fi 4 (802.11n), 2x2:2 MIMO, 40 MHz, 64-QAM, 300 Mbps PHY
10/100/1000 Mbps Gigabit Ethernet
upstream WAN network internal LAN Gigabit tests - link
PC1
Wi-Fi 6 (802.11ax), 2x2:2 MIMO, MU-MIMO, OFDMA, HE80, 1024-QAM
10/100/1000 Mbps Gigabit Ethernet
PC2
Wi-Fi 6 (802.11ax), 2x2:2 MIMO, MU-MIMO, OFDMA, HE160, 1024-QAM
10/100/1000 Mbps Gigabit Ethernet
Test Results
Case 1 — Wireless Router Mode: Ethernet LAN Client → Ethernet WAN Server
For the first test, I connected the TR1200 to the upstream WAN network through its WAN Ethernet port. I connected PC1 to the TR1200's LAN port and PC2 to an Ethernet LAN port on the upstream network. I then started the iperf3 server on PC2.
This setup allowed me to test the Ethernet throughput and stability of the LAN-to-WAN path through the Cudy TR1200.
The LAN-to-WAN Ethernet tests made the practical bandwidth limits of the connection fairly clear. While pushing throughput toward the 90 Mbit/s range, I also observed intermittent packet loss during the UDP test.
Out of all four scenarios, this produced by far the worst results. I originally expected the wireless connection to exhibit more packet loss or throughput fluctuations, but instead I encountered significantly higher packet loss and much more noticeable throughput variation in this wired scenario.
To rule out problems with the lab environment, I repeated the test using several combinations of routers, PCs, and Ethernet cables, but none of these changes had a meaningful impact on the results.
Once I install OpenWrt on the TR1200, I plan to repeat this scenario. If I continue to see the same behavior, I will cover the possible causes and, if possible, solutions in a separate blog post.
- TCP Throughput Test:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 147 MBytes 20.5 Mbits/sec 206 sender
[ 5] 0.00-60.02 sec 147 MBytes 20.5 Mbits/sec receiver
[ 7] 0.00-60.00 sec 150 MBytes 21.0 Mbits/sec 179 sender
[ 7] 0.00-60.02 sec 150 MBytes 21.0 Mbits/sec receiver
[ 9] 0.00-60.00 sec 150 MBytes 21.0 Mbits/sec 190 sender
[ 9] 0.00-60.02 sec 150 MBytes 21.0 Mbits/sec receiver
[ 11] 0.00-60.00 sec 153 MBytes 21.4 Mbits/sec 212 sender
[ 11] 0.00-60.02 sec 153 MBytes 21.3 Mbits/sec receiver
[SUM] 0.00-60.00 sec 601 MBytes 84.0 Mbits/sec 787 sender
[SUM] 0.00-60.02 sec 599 MBytes 83.8 Mbits/sec receiver
iperf Done.
- Packet Loss Test:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.000 ms 0/278186 (0%) sender
[ 5] 0.00-60.00 sec 356 MBytes 49.7 Mbits/sec 0.257 ms 1443/278186 (0.52%) receiver
iperf Done.
Detailed test results - link
Case 2 — Wireless Router Mode: Wireless LAN Client → Ethernet WAN Server
For this test, I changed the previous setup by connecting to the TR1200's LAN over Wi-Fi instead of Ethernet and then repeated the same tests.
Compared with the previous scenario, UDP packet loss on the wireless LAN connection dropped significantly, although I also observed a reduction in throughput.
- TCP Throughput Test:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 121 MBytes 16.9 Mbits/sec 63 sender
[ 5] 0.00-60.01 sec 120 MBytes 16.8 Mbits/sec receiver
[ 7] 0.00-60.00 sec 121 MBytes 17.0 Mbits/sec 63 sender
[ 7] 0.00-60.01 sec 121 MBytes 16.9 Mbits/sec receiver
[ 9] 0.00-60.00 sec 121 MBytes 16.9 Mbits/sec 65 sender
[ 9] 0.00-60.01 sec 121 MBytes 16.9 Mbits/sec receiver
[ 11] 0.00-60.00 sec 123 MBytes 17.2 Mbits/sec 64 sender
[ 11] 0.00-60.01 sec 123 MBytes 17.1 Mbits/sec receiver
[SUM] 0.00-60.00 sec 486 MBytes 67.9 Mbits/sec 255 sender
[SUM] 0.00-60.01 sec 485 MBytes 67.8 Mbits/sec receiver
iperf Done.
- Packet Loss Test:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.000 ms 0/278186 (0%) sender
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.168 ms 27/278186 (0.0097%) receiver
iperf Done.
Case 3 — WISP Mode: Ethernet LAN Server ↔ Ethernet LAN Client
For this scenario, I switched the TR1200 to WISP mode and connected it wirelessly to the upstream WAN network instead of using a wired WAN connection.
Since the physical WAN port was no longer needed for the uplink, I reconfigured it as a LAN port through the TR1200's interface. This allowed me to connect two Ethernet clients directly to the router's two physical Ethernet ports.
Rather than testing traffic across the WAN, I ran the tests entirely within the local Ethernet LAN to measure the TR1200's internal LAN forwarding capacity.
The UDP test completed with zero packet loss, while the TCP test reached an average throughput of approximately 94 Mbit/s. These results are very close to the values expected from the Ethernet interfaces and represent an ideal result for this setup.
- Packet Loss Test:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.000 ms 0/258975 (0%) sender
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.242 ms 0/258972 (0%) receiver
iperf Done.
- TCP Throughput Test:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 169 MBytes 23.6 Mbits/sec 0 sender
[ 5] 0.00-60.01 sec 168 MBytes 23.5 Mbits/sec receiver
[ 7] 0.00-60.00 sec 169 MBytes 23.6 Mbits/sec 4 sender
[ 7] 0.00-60.01 sec 168 MBytes 23.5 Mbits/sec receiver
[ 9] 0.00-60.00 sec 169 MBytes 23.6 Mbits/sec 3 sender
[ 9] 0.00-60.01 sec 168 MBytes 23.5 Mbits/sec receiver
[ 11] 0.00-60.00 sec 168 MBytes 23.5 Mbits/sec 1 sender
[ 11] 0.00-60.01 sec 168 MBytes 23.5 Mbits/sec receiver
[SUM] 0.00-60.00 sec 674 MBytes 94.3 Mbits/sec 8 sender
[SUM] 0.00-60.01 sec 673 MBytes 94.1 Mbits/sec receiver
iperf Done.
Case 4 — WISP Mode: Wireless LAN Server ↔ Wireless LAN Client
Finally, I tested the bandwidth limits of the wireless LAN while the TR1200 was operating in WISP mode.
During the 50 Mbit/s UDP test, I observed no packet loss. In the 5 GHz wireless LAN TCP test, throughput reached approximately 151 Mbit/s. This scenario produced the best overall results of the four tests.
- Packet Loss Test:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 358 MBytes 50.0 Mbits/sec 0.000 ms 0/258975 (0%) sender
[ 5] 0.00-60.05 sec 358 MBytes 50.0 Mbits/sec 0.258 ms 0/258975 (0%) receiver
iperf Done.
- TCP Throughput Test:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 256 MBytes 35.8 Mbits/sec 49 sender
[ 5] 0.00-60.05 sec 254 MBytes 35.4 Mbits/sec receiver
[ 7] 0.00-60.00 sec 275 MBytes 38.5 Mbits/sec 51 sender
[ 7] 0.00-60.05 sec 273 MBytes 38.2 Mbits/sec receiver
[ 9] 0.00-60.00 sec 278 MBytes 38.8 Mbits/sec 94 sender
[ 9] 0.00-60.05 sec 274 MBytes 38.3 Mbits/sec receiver
[ 11] 0.00-60.00 sec 283 MBytes 39.6 Mbits/sec 93 sender
[ 11] 0.00-60.05 sec 280 MBytes 39.2 Mbits/sec receiver
[SUM] 0.00-60.00 sec 1.07 GBytes 153 Mbits/sec 287 sender
[SUM] 0.00-60.05 sec 1.06 GBytes 151 Mbits/sec receiver
iperf Done.
Overall Assessment
On the TR1200, I observed acceptable jitter levels alongside occasional periods of packet loss and throughput fluctuation, with the problems sometimes becoming more noticeable at roughly 30-second intervals.
I suspect this behavior may be related to the stability of the stock firmware and the router's single-core processor. During testing, I tried different PCs and Ethernet cables in an attempt to isolate the source of the packet loss, but these changes had no meaningful effect on the results.
For workloads such as online meetings or long-lived socket-based connections, I would expect these intermittent issues to occasionally result in noticeable interruptions.
That said, considering the price of the device and the fact that it is designed as a compact travel router, I still believe these limitations remain within an acceptable range.
I also plan to install OpenWrt on the TR1200 soon, and I am interested to see whether these issues improve with a different firmware stack.
Pros:
- Small and lightweight for a travel router
- Built-in VPN support in the stock Cudy firmware
- Ability to distribute a WAN connection over wired or wireless interfaces using NAT or bridge modes
- 5 GHz wireless performance is sufficient for everyday office workloads
- Very low power consumption, averaging around 1–2 W in my setup while operating in WISP mode with an upstream WAN connection and Wi-Fi enabled
Cons:
- Periodic packet loss observed on both Ethernet and wireless connections
- In my LAN-to-WAN tests, the wired scenario showed higher packet loss than the wireless scenario
- According to Cudy's published figures, WireGuard client throughput is limited to approximately 43–49 Mbps
Top comments (0)