PS Remote Play 2026: 12 Steps to 1080p HQ in 30 Min

PS Remote Play is Sony streaming your own console to your own screen across your own network, and it remains the most quietly mishandled feature on the PS5. It is free. It has shipped, in one shape or another, since 2006. And in 2026 the single most common failure mode is identical to the one from a decade ago: somebody plugs the console into Wi-Fi, watches the picture dissolve into a smear of macroblocks, and concludes the technology is broken. The technology is fine. Your network is the problem, and this article is twelve steps of fixing it.

What follows is the deadpan version. Every setting that matters. The bandwidth arithmetic Sony buries three clicks deep in a support article. The ports your router pretends not to recognize. The open-source client that quietly does the job better than the official one. And a complete, copyable configuration at the end. The target outcome is concrete: 1080p at 30 frames per second over a 15 Mbps link, under 40 milliseconds of added latency on a wired LAN, and a session that does not collapse the instant someone in the next room starts downloading a 90 GB shooter.

Remote Play Is Older Than You Think

From the PSP to the Portal

Remote Play is not a 2023 invention conjured to sell you a handheld. It shipped with the PSP in 2006, which could pull a thin slice of the PS3 across your home network and, briefly, over the open internet, a genuinely radical idea wrapped in genuinely miserable execution, because consumer broadband in 2006 was not ready and neither was the PSP's 802.11b radio. The PS Vita made it a headline feature in 2011 and pushed it hard through 2013, promising the PS4 in your hands anywhere in the house. The PS4 era turned it into a first-class citizen with official Windows and macOS apps. The PS5 added HEVC encoding and the bandwidth headroom to make 1080p plausible instead of aspirational.

The PlayStation Portal, launched in November 2023 at an MSRP of $199.99, is that same lineage poured into a dedicated eight-inch shell with no local game processing of its own. It is a Remote Play screen with two DualSense halves bolted to either side, and nothing more. People keep reviewing it as if it were a console; it is a monitor with a Wi-Fi card and a grudge. On March 18, 2024 Sony pushed it a software update that added a 1080p 'High Quality' mode and tightened the UX, which is the most recent materially significant change to the Remote Play stack and the reason the 1080p numbers in this guide are worth chasing.

What it actually is in 2026

Strip the marketing and Remote Play is three things bolted together: a low-latency video codec, a bidirectional control channel, and a discovery handshake. The console encodes its video output in real time, H.264 on the PS4, HEVC (H.265) on the PS5, fragments it into packets, and ships them to a client that decodes and displays the frames while shoveling your controller inputs back the other direction over a separate, latency-sensitive path. The audio rides alongside in its own buffered stream. That is the entire trick.

The whole edifice lives or dies on two numbers almost nobody measures: end-to-end latency and sustained throughput. Get both right and Remote Play feels like a slightly soft local console, a half-frame of extra delay you stop noticing inside ten minutes. Get either wrong and it feels like playing through a parking-lot security camera during a hailstorm. Most 'Remote Play is bad' complaints are latency complaints wearing a resolution costume, because the human eye forgives a soft image far more readily than it forgives a controller that answers a beat late.

The official app versus the honest one

There are two legitimate ways to do this, and you should know both exist. Sony's official PS Remote Play app is free, runs on Windows, macOS, Android, iOS, and the Portal, and is the correct starting point for roughly everyone. The other way is chiaki-ng, the actively maintained successor to Chiaki, an open-source client that reverse-engineered the protocol and now runs on Linux, the BSDs, Windows, macOS, Android, the Nintendo Switch, and a drawer full of handhelds Sony will never bless. The original Chiaki, by Florian Maerkl, is now in maintenance mode and lives on SourceHut; chiaki-ng is where the work happens now. We will set up both, because the official app is convenient and chiaki-ng is better at the things that actually decide quality: codec selection, manual bitrate control, hardware-decoder choice, and not silently collapsing to 540p the moment it sees a single dropped packet.

Prerequisites: Hardware, Software, Versions

The console side

You need a PS5 (any model, including the Pro) or a PS4, with the system software fully updated. Sony does not publish a meaningful version floor for Remote Play, because it ships as part of the base firmware rather than as a separate app, so the rule is simply: take every update, every time, and do not skip the ones that say 'improves system performance' because that is Sony-speak for 'we changed something in the network stack.' The account that owns the console must be the one that registers each client, because Remote Play registration is per-account, cryptographically tied to your PSN identity, not a free-for-all per device.

The console must be connected to your router by Ethernet. This is not a stylistic preference and it is not negotiable if you care about the result; the entire next section exists to explain why. If your console physically cannot reach the router, a pair of powerline adapters or a MoCA bridge beats Wi-Fi for this purpose nearly every time, because what Remote Play needs from the console's link is not raw speed but consistency: low jitter and zero packet loss under sustained upstream load.

The client side

The client is whatever you are playing on. Sony's published OS minimums drift between app versions and their own page is allergic to specifics, so treat the table below as the practical floor rather than gospel. The one number that is not vague is bandwidth, and it is the same regardless of platform.

A note on the Portal line in that table: the $199.99 device is the only piece of hardware here you actually have to buy, and it does exactly one thing. If you already own a phone, a tablet, a laptop, or a handheld PC, you own a Remote Play client already, and the Portal buys you convenience and a good screen, not capability. We compared the handheld-PC options in detail elsewhere; more on that in the advanced section.

The network floor, stated bluntly

Here are the numbers, restated without the support-article hedging. Sony's documented minimum is 5 Mbps in both directions. For 1080p at 30 fps, the 'High Quality' tier that reached the Portal on March 18, 2024 and exists in every app as the 1080p resolution option, you want at least 15 Mbps, again in both directions, measured at both ends of the connection. The phrase 'both directions' is the part people skip and then regret. The console uploads; the client downloads. The instant you play away from home those roles invert relative to your two different connections, so a classic asymmetric consumer plan, a fat 300 Mbps download line yoked to a sad 10 Mbps upload, is a Remote Play death sentence the moment you leave the house, no matter how impressive the download figure looks on the box. Sony's own streaming-quality guidance confirms the 5-and-15 split if you can find it.

The Network Reality Nobody Admits

Bandwidth is necessary; latency is the boss

Bandwidth and latency are different problems and people conflate them constantly. Bandwidth is how much data per second the pipe can carry; latency is how long any single packet takes to traverse it. Remote Play needs enough bandwidth to carry a 1080p HEVC stream, call it 10 to 15 Mbps with headroom, but it needs that bandwidth delivered with low, stable latency. A 1 Gbps connection that periodically spikes to 200 ms of delay under load will play worse than a steady 20 Mbps line that never wavers, because the encoder and decoder are running a tight feedback loop and every latency spike forces a stall, a dropped frame, or a panicked drop in bitrate.

The villain here is usually bufferbloat: oversized, unmanaged buffers in your modem or router that fill up under load and add hundreds of milliseconds of queuing delay precisely when the household starts using the connection. You can have a pristine 15 ms idle ping and a catastrophic 300 ms ping the second a cloud backup kicks off, and Remote Play will feel the difference even though your speed test still reads green. The fix is active queue management, CAKE or fq_codel via SQM, capping your uplink slightly below its true rate so the smart queue, not the dumb modem buffer, decides what waits. We will configure exactly that in the advanced section.

NAT, CGNAT, and the 9295-9304 problem

On your home LAN, discovery and connection are automatic and you will rarely think about ports. Over the internet it is a different story, and the relevant facts are these. Remote Play uses TCP port 9295 for the session and registration handshake, and UDP ports 9296 and 9297 for the actual streaming. If those are blocked or contended, the protocol can fall back across the range 9295 to 9304 on both TCP and UDP, and discovery historically rides UDP 9302/9303. You do not have to memorize that; you have to make sure your router either supports UPnP, in which case the console opens what it needs on demand, or has those ports forwarded statically to the console's address. The community reference at portforward.com lists the exact mappings if you go the manual route.

The thing that will genuinely defeat you is carrier-grade NAT. If your ISP has run out of IPv4 addresses and put you behind CGNAT, you share a public address with strangers and you cannot accept inbound connections at all, which means port forwarding is pointless and Remote Play over the internet simply will not establish. The tells are a WAN IP in the 100.64.0.0/10 range, or a router whose 'external' address does not match what a what-is-my-IP page reports. The honest fixes are: ask your ISP for a real or static IP (sometimes free, sometimes a few dollars a month), or route around the whole mess with an overlay network like Tailscale, which we cover later.

Wi-Fi is the enemy, mostly

Wi-Fi is fine for the client and poison for the console. The reason is asymmetry of consequence. The client is downloading a stream it can buffer slightly; the console is uploading a real-time stream where a single 40 ms airtime collision becomes a visible hitch. Put the console on 2.4 GHz in a dense apartment and you are sharing a handful of overlapping channels with every microwave, baby monitor, and neighbor in radio range; the result is jitter that no amount of bandwidth will paper over.

So: wire the console, always. For the client, prefer 5 GHz (or 6 GHz on Wi-Fi 6E) and stand near the access point; the 5 GHz band has more non-overlapping channels and far less legacy interference, at the cost of range. If your client must use Wi-Fi and the picture stutters in a predictable rhythm, that rhythm is almost always your Wi-Fi retransmitting, not your internet failing. The single highest-leverage change most people can make to Remote Play quality costs about eight dollars and is called an Ethernet cable.

The 12-Step Setup

Steps 1-4: prepare the console

1. Update the PS5 completely. Settings > System > System Software > System Software Update and Settings. Install everything, reboot, check again. Rationale: Remote Play's encoder and network stack are part of firmware, and Sony has historically shipped Remote Play fixes inside generic 'performance' updates with no patch notes worth reading. An out-of-date console is the one variable you can eliminate for free in two minutes.
2. Wire the console to the router. Plug an Ethernet cable from the PS5 into a LAN port, then run Settings > Network > Connection Status > Test Internet Connection and confirm it reports the wired interface. Rationale: the console is the uploader; its link must be jitter-free and loss-free under sustained load, and Wi-Fi cannot reliably promise that. This single step fixes more Remote Play complaints than every other step combined.
3. Enable Remote Play. Settings > System > Remote Play > Enable Remote Play, toggle on. Rationale: it is off by default, and the app's 'cannot find your console' error is, more often than people admit, this toggle sitting in the off position. Turn it on before you blame anything else.
4. Configure rest-mode wake. Settings > System > Power Saving > Features Available in Rest Mode, then enable both 'Stay Connected to the Internet' and 'Enable Turning On PS5 from Network.' Rationale: without these two, the console either drops off the network in rest mode or refuses to wake remotely, and you will be left with a device you can only reach while it is already fully on, which defeats the entire point of connecting from the office or a hotel.

Steps 5-8: link and pair the client

1. Install the official PS Remote Play app. Get it from Sony's Remote Play page for desktop, or the App Store / Google Play for mobile; install the Portal's updates if that is your client. Rationale: even if you intend to live in chiaki-ng, the official app is the fastest way to confirm the console-side setup is correct before you add the complexity of a third-party client.
2. Sign in with the owning PSN account. Launch the app and sign in with the same account that owns the console. Rationale: registration is per-account and cryptographic; signing in with a different account will either fail outright or register a guest session with fewer rights. Match the account and this step is invisible.
3. Pair for the first time on the same LAN. With the console awake and on the same network, let the app discover it automatically and connect once. Rationale: first-time registration exchanges a key, and doing it on the LAN removes NAT, ports, and the internet from the equation, so a failure here is unambiguously a local problem, not a routing one.
4. Set a conservative resolution and frame rate. In the app's settings, start at 1080p resolution and 'Standard' frame rate (30 fps). Rationale: you are establishing a working baseline, not chasing a benchmark. Thirty stable frames at 1080p look and feel better than sixty frames that constantly stutter, and you can raise the ceiling later once you have measured the link.

Steps 9-12: harden and tune

1. Connect on the LAN and read the stats. Play for five minutes on the local network and watch for hitches; in chiaki-ng, enable the on-screen stats overlay. Rationale: the LAN is your control case. If it is not flawless here, with effectively unlimited bandwidth and sub-millisecond latency, no amount of internet tuning will save the remote case.
2. Enable UPnP or forward the ports. In your router, enable UPnP; if you refuse to (a defensible security position), statically forward TCP 9295 and UDP 9296-9297 to the console's reserved IP. Rationale: this is what lets the session establish from outside your home. Skip it and Remote Play works on the couch and dies at the coffee shop.
3. Test over the internet. Put the client on cellular data or a different network and connect from outside your LAN. Rationale: this is the only test that actually proves your NAT, ports, and upstream bandwidth cooperate. The couch test proves nothing about the real-world case you bought this for.
4. Turn on QoS/SQM, then raise the ceiling. Enable smart queue management on the router to tame bufferbloat, then, only on a link you have measured at 15 Mbps or better in both directions with low jitter, push resolution to 1080p 'High Quality' and frame rate to 'High' (60 fps). Rationale: tuning order matters. Stabilize the queue first, then spend the headroom; do it in the other order and you are just adding bitrate to a connection that cannot keep its latency under control.

Settings and Config Files

The official app's quality settings

The official app hides everything behind one gear icon and gives you exactly two dials that matter: resolution and frame rate. There is no manual bitrate, no codec selector, no hardware-decoder choice; the app decides for you and degrades silently when the link struggles. Here is the entire surface area, annotated for what it actually costs you.

# PS Remote Play  >  Settings (gear)  >  Video Quality for Remote Play
Resolution :  1080p        # PS5 only; needs 15 Mbps+ both ends
Frame Rate :  Standard     # 30 fps (safer).  'High' = 60 fps (hungrier)

# If the image breaks up, walk it back in this order:
#   1080p  ->  720p (High)  ->  540p (Standard)
# No bitrate or codec control here. That gap is the whole case for chiaki-ng.

The app's silent degradation is its defining weakness. When packets drop it will quietly fall to 720p or 540p and stay there, often long after the network has recovered, leaving you staring at a soft image and wondering why. The only remedy in the official app is to disconnect and reconnect. This is precisely the behavior chiaki-ng was built to escape.

chiaki-ng: resolution, codec, and bitrate

chiaki-ng exposes the knobs the official app hides. You register a console once, then open the console tile's settings and tune. The values below are the ones that change the experience; the rest are sensible at their defaults. The full reference lives in the chiaki-ng documentation, which is worth reading once in full.

# chiaki-ng  >  console tile  >  Settings (pencil)
Resolution     : 1080p          # 720p if the overlay shows packet loss
FPS            : 60             # 30 on a marginal link
Codec          : H265 (HEVC)    # PS5 only; H264 for PS4 or fussy decoders
Bitrate        : auto           # or pin ~15000 Kbps to match a 15 Mbps line
HW Decoder     : vaapi          # nvdec / videotoolbox / d3d11va per platform
Audio buffer   : 9600           # raise if audio crackles or drifts

The single most useful thing chiaki-ng gives you is the codec selector. On a PS5 you want H265 (HEVC), which carries a markedly cleaner 1080p image at the same bitrate than H.264 because of more efficient compression; H.264 exists for the PS4 and for the rare decoder that chokes on HEVC. The second most useful thing is the hardware-decoder selector, which offloads decode to your GPU, VAAPI on Intel/AMD Linux, NVDEC on NVIDIA, VideoToolbox on macOS and iOS, D3D11VA on Windows, dropping decode latency from tens of milliseconds to low single digits.

The Chiaki.conf file itself

chiaki-ng stores its settings in a Qt-style INI file, which you can edit directly when you want to script a setup or copy a known-good configuration between machines. On a standard install it lives at ~/.config/Chiaki/Chiaki.conf; on the Flatpak it is sandboxed under the app's data directory. Key names vary slightly between releases, so treat this as a representative shape rather than a byte-exact template.

; ~/.config/Chiaki/Chiaki.conf
; flatpak: ~/.var/app/io.github.streetpea.Chiaki4deck/config/Chiaki/Chiaki.conf
[settings]
resolution=1080p
fps=60
codec=h265
bitrate=15000
hardware_decoder=vaapi
audio_buffer_size=9600
auto_connect_host=192.168.1.42

[registered_hosts]
1\host_name=PS5-Living-Room
1\server_mac=@ByteArray(...)
1\rp_key=@ByteArray(...)     ; secret. do not share, do not commit.

One line in there deserves a warning: the registration key (rp_key, stored as a Qt ByteArray) is the secret that authorizes your client to wake and stream your console. Treat the file like a password. Do not paste it into a forum thread when you ask for help, do not commit it to a public dotfiles repo, and regenerate it from the console if you ever suspect it leaked by re-registering the device.

What Success Looks Like

The bandwidth and latency baseline

Before you blame Sony, measure your own network, because a green speed-test result tells you almost nothing about the metrics Remote Play cares about: sustained UDP throughput and loss, and latency under load. Two commands establish the baseline. On the LAN, an iperf3 run against the console's subnet (or any wired host on it) proves the local path is clean; a ping proves the round-trip is tight.

$ iperf3 -c 192.168.1.42 -u -b 20M
[  5]  0.00-10.00 sec  23.8 MBytes  20.0 Mbits/sec  0.142 ms  0/17142 (0%)
# 0% UDP loss on the LAN = pass. Sustained loss here = bad cable/switch/Wi-Fi.

$ ping -c 5 192.168.1.42
64 bytes from 192.168.1.42: icmp_seq=1 ttl=64 time=0.6 ms
rtt min/avg/max/mdev = 0.5/0.7/0.9/0.1 ms
# Sub-1 ms on the LAN. Over the internet, aim under 30 ms; past 60 ms gets sloppy.

The number to fixate on is loss, not speed. Zero percent UDP loss on the LAN is the pass condition; any sustained loss there points at a bad cable, a dying switch port, or a Wi-Fi link you forgot was in the path. Over the internet, run the same ping against your public endpoint while someone saturates the connection: if idle latency is 20 ms and loaded latency is 200 ms, you have bufferbloat, not bad luck.

The in-stream stats overlay

Numbers from outside the stream are circumstantial; the stream's own telemetry is the verdict. chiaki-ng can paint a live overlay of resolution, frame rate, codec, bitrate, decode time, and dropped/corrupt frame counters directly over the game. The official app offers only a coarse connection-quality indicator, which is one more reason to graduate to chiaki-ng once you are past the basics.

chiaki-ng on-screen stats (toggle in-session):
  res 1920x1080   fps 59-60   codec HEVC
  bitrate 14.8 Mbps   decode 4.1 ms   jitter 1.2 ms
  dropped 0   corrupt 0
# Healthy: fps near target, dropped/corrupt at 0, decode in single-digit ms.

A healthy readout has frame rate pinned within a frame or two of your target, dropped and corrupt counters sitting at zero, decode time in the single-digit milliseconds (proof your hardware decoder is engaged), and bitrate sitting near your configured ceiling rather than sagging. If frame rate is fine but bitrate is sagging and the image looks soft, your encoder is throttling to protect latency, which means the bottleneck is the network, not the console.

A clean registration and discovery

When the console is set up correctly, discovery is instantaneous and unambiguous. chiaki-ng ships a command-line discovery tool that will report a console's state and registration status without launching the GUI, which is the fastest way to confirm steps 3 and 4 actually took.

$ chiaki discover -h 192.168.1.42
Host:         192.168.1.42
State:        ready        # 'standby' = rest mode; both connect if step 4 is done
Host Type:    PS5
Registered:   true

A state of 'ready' means the console is awake; 'standby' means it is in rest mode and will need the wake packet, both are connectable if you completed step 4. If discovery returns nothing at all, the console is either powered fully off, on a different subnet, or has Remote Play disabled, and you are back to steps 2 through 4 before anything else is worth trying.

Five Pitfalls That Wreck the Stream

Pitfall 1: the console on Wi-Fi

This is the original sin and it accounts for the majority of 'Remote Play is unplayable' posts. The console is the uploader, and a wireless uplink introduces jitter and intermittent loss that the real-time encoder cannot hide. The symptom is a stream that is fine for thirty seconds and then hitches hard, repeatedly, on no obvious trigger. The fix is one Ethernet cable from the PS5 to the router. If a cable run is impossible, MoCA over your coax or a decent powerline adapter both beat Wi-Fi for this specific job, because consistency, not peak speed, is what the uplink needs to deliver.

Pitfall 2: rest-mode wake left half-configured

People enable Remote Play, skip the power-saving toggles, and then cannot understand why the console is unreachable whenever it sleeps. Remote Play needs the console to stay on the network in rest mode and to accept a wake packet, and those are two separate switches buried under Power Saving, not under Remote Play. Enable both 'Stay Connected to the Internet' and 'Enable Turning On PS5 from Network.' If the console keeps fully powering off anyway, check that you did not enable a power schedule or that a firmware update did not reset the rest-mode features after rebooting.

Pitfall 3: bufferbloat from the household

The stream is perfect until a roommate's machine starts a cloud sync or a game preloads, and then the picture falls apart even though your plan is allegedly 'gigabit.' This is bufferbloat: an unmanaged modem buffer filling under load and adding hundreds of milliseconds of delay to every packet, Remote Play's included. No bandwidth upgrade fixes it because the problem is queue management, not capacity. Enable SQM (CAKE) on your router and cap the uplink to roughly 90 percent of its measured rate; the configuration is in the advanced section. If the console itself starts behaving strangely after a long uptime, a separate gremlin, clearing its cache from safe mode is the cheap first move.

Pitfall 4: double NAT and carrier-grade NAT

Two routers in series, your own behind an ISP gateway that is also routing, create a double NAT, and inbound Remote Play connections die in the gap between them. Worse is CGNAT, where the ISP shares one public address across many customers and you cannot accept inbound connections at all. Diagnose it by comparing your router's WAN address to a what-is-my-IP lookup; if they differ, or your WAN IP is in the 100.64.0.0/10 range, you are behind something. The fixes, in order of preference: put the ISP gateway in bridge mode to eliminate the double NAT, ask the ISP for a non-CGNAT or static IP, or tunnel out with Tailscale and stop fighting the carrier entirely.

Pitfall 5: forcing 1080p over a link that cannot carry it

Resolution is not free, and 1080p 'High Quality' over a 6 Mbps uplink is a worse experience than honest 720p, because the encoder spends its entire time budget throttling and recovering. If your measured upload is below 15 Mbps, or your loaded latency is ugly, drop to 720p and 30 fps and enjoy a stable picture. The point of Remote Play is responsiveness; chasing a resolution number your network cannot sustain trades the thing that matters for the thing that photographs well. Measure first, then set the ceiling to match reality.

Pitfall 6: confusing Console Sharing with Remote Play linking

'Console Sharing and Offline Play' and Remote Play registration are different features that share a neighborhood in the menus, and people toggle the wrong one. Console Sharing governs which account's licenses the console honors when you are not signed in; Remote Play registration is the cryptographic pairing that lets a client connect. Setting one does not set the other. If a freshly installed client refuses to register despite a correct account, confirm you completed the Remote Play link step on the console and that you are not staring at the licensing screen wondering why nothing happened.

The Troubleshooting Table

When the connection will not establish

Failures to connect are almost always one of four things: the console is off or off-network, Remote Play or rest-mode wake is disabled, the account does not match, or NAT and ports are blocking the path from outside. Work them in that order, cheapest and most common first, and do not start forwarding ports before you have confirmed the console answers on the LAN.

When the picture stutters or softens

Stutter is a latency-and-loss problem; softness is a bitrate problem. They have different causes and different fixes, and the stats overlay tells you which one you have. Rhythmic stutter points at Wi-Fi retransmission; load-triggered stutter points at bufferbloat; a persistently soft image points at a throttled encoder or a link that cannot sustain your chosen resolution.

When input or audio lags

Input lag that the picture does not share is usually a controller-connection problem at the client, not a streaming problem; audio that crackles or drifts is a buffer-size problem. The table covers the specific moves for each.

Advanced: Chiaki, QoS, and Handhelds

Why chiaki-ng beats the official app

Once the basics work, chiaki-ng is the upgrade that earns its complexity. It lets you pin a codec instead of accepting the app's choice, set a fixed bitrate instead of riding its silent auto-throttle, choose a hardware decoder to cut decode latency, and, crucially, it does not stampede down to 540p and stay there at the first dropped packet. It also runs where the official app refuses to: Linux, the Steam Deck, the Switch, and a range of Android handhelds. The project is active; it shipped improved controller mapping in early 2025 among other refinements. The catch is honesty: chiaki-ng authenticates with your real account registration, but it is unofficial, and Sony offers it neither blessing nor support.

Killing bufferbloat with SQM and CAKE

The highest-leverage network change after wiring the console is smart queue management. On OpenWrt it is a few UCI commands; on a stock router, look for a 'QoS', 'Smart Queue', or 'Bufferbloat' setting and enable it. The principle is identical everywhere: deliberately cap your throughput just under the line's true rate so a managed queue, CAKE or fq_codel, decides packet order, instead of letting the modem's dumb buffer balloon under load. Measure your real rates first (a bufferbloat-aware speed test will do), then cap to roughly 90 percent of upload and 95 percent of download.

# OpenWrt: cap uplink just under the true rate; let CAKE manage the queue
uci set sqm.@queue.interface='eth1'      # your WAN interface
uci set sqm.@queue.download='190000'     # ~95% of measured down (Kbit/s)
uci set sqm.@queue.upload='18000'        # ~90% of measured up   (Kbit/s)
uci set sqm.@queue.qdisc='cake'
uci set sqm.@queue.script='piece_of_cake.qos'
uci commit sqm
/etc/init.d/sqm restart

If your router supports DSCP-based prioritization, you can additionally tag Remote Play's traffic for the low-latency queue, but on a properly tuned CAKE setup the flow isolation usually makes that unnecessary. Verify the win the same way you found the problem: ping under load and confirm the loaded latency now stays within a few milliseconds of idle. If you also want to forward ports by hand and confirm UPnP is doing its job, the miniupnpc tools will list the active mappings.

$ upnpc -l | grep 929
 0 UDP  9296 -> 192.168.1.42:9296  'PS5-RemotePlay'
 1 UDP  9297 -> 192.168.1.42:9297  'PS5-RemotePlay'
 2 TCP  9295 -> 192.168.1.42:9295  'PS5-RemotePlay'
# If these appear after a connect attempt, UPnP is doing its job.

Handheld clients and Tailscale

The most satisfying Remote Play setups in 2026 are not phones; they are handheld PCs running chiaki-ng with hardware decode and real controls. A Steam Deck OLED or a ROG Ally X makes an outstanding client, and the difference between the two is mostly screen and battery, which we broke down in our Ally X versus Steam Deck OLED comparison. On a tighter budget, an Android handheld like the Retroid Pocket 6 runs the Android build perfectly well. For the WAN-connectivity headache, CGNAT, double NAT, ports you would rather not open, an overlay network like Tailscale puts client and console on the same virtual LAN, sidesteps inbound NAT entirely, and makes the internet case behave like the couch case. If you want to record the session you are streaming, route the client's output through OBS rather than trusting any built-in capture.

The Complete Working Configuration

The console checklist

Everything on the console side, in one place. If you can tick every line, the console is not your problem.

• System software fully updated; reboot performed.
• Wired Ethernet to the router, confirmed in Connection Status.
• DHCP reservation set so the console keeps a fixed LAN IP.
• Remote Play enabled (Settings > System > Remote Play).
• Rest mode: 'Stay Connected to the Internet' on.
• Rest mode: 'Enable Turning On PS5 from Network' on.
• Client registered with the owning PSN account.

The router configuration

The router side is a DHCP reservation, either UPnP or three static forwards, a sane queue, and single NAT. The block below is the whole thing; adapt the addresses and rates to your network.

# ============ PS5 (console) ============
Network      : Wired Ethernet, DHCP reservation 192.168.1.42
Remote Play  : Enabled
Rest mode    : Stay Connected to the Internet    = On
               Enable Turning On PS5 from Network = On

# ============ Router ============
UPnP         : Enabled            # or the static forwards below
Forward TCP  : 9295        -> 192.168.1.42
Forward UDP  : 9296-9297   -> 192.168.1.42
Fallback     : 9295-9304   -> 192.168.1.42   (TCP + UDP, if needed)
SQM/QoS      : CAKE, uplink capped to ~90% of measured rate
NAT          : Single NAT (ISP gateway in bridge mode; not behind CGNAT)

# ============ Client (chiaki-ng) ============
resolution=1080p
fps=30          # raise to 60 only on a verified 15+ Mbps, low-jitter link
codec=h265
bitrate=15000
hardware_decoder=auto
audio_buffer_size=9600

The client configuration

The client section sits at the bottom of that same reference block: start conservative, with 30 fps and a pinned 15000 Kbps bitrate, and raise the ceiling only after the link is measured and the queue is tuned. That is the configuration that produces the target outcome stated at the top: a stable 1080p30 over 15 Mbps, with 60 fps available the moment your network earns it.

That is the entire system. Console wired and awake-capable, router queuing intelligently and reachable from outside, client decoding in hardware with a codec and bitrate you chose on purpose. Do this and Remote Play stops being the flaky party trick people complain about and becomes what it was always supposed to be since that first stuttering PSP stream in 2006: your console, in your hands, anywhere the network is honest. If you would rather have zero-latency local play and never touch a router again, a capture card is the honest alternative, but that is a different article.

The Verdict

When Remote Play is the right tool

Remote Play is the right tool when the console and the client are on networks you control or can measure, when your upload clears 15 Mbps at both ends, and when responsiveness matters more to you than the last increment of image fidelity. In that envelope it is genuinely excellent and effectively free, and the $199.99 Portal is a reasonable convenience purchase if you want a dedicated screen rather than tying up a phone. For playing your own library from another room, the office, or a hotel with a sane network, nothing else is this frictionless.

When to reach for something else

It is the wrong tool when you are behind CGNAT with no overlay, when your uplink is a single-digit-megabit afterthought, or when you need frame-perfect timing for fighting games and twitch shooters where even 30 ms of added latency is disqualifying. In those cases, stop fighting physics: play locally, or capture the console directly. Remote Play is a brilliant solution to a network problem, not a way to repeal the speed of light. Set it up correctly, measure honestly, and it will do exactly what it promises, no more, and refreshingly, no less.