Chế độ ngủ khi truy cập từ xa: Giữ máy luôn hoạt động

You're trying to connect to a remote machine and it won't answer — because it went to sleep. This guide cuts past myths and gives concrete "keep-awake" patterns that actually work for remote desktop workflows: when to prevent sleep, when to rely on Wake-on-LAN, and how to do both safely on Windows, macOS and Linux.

How sleep states break remote access

Understanding what "sleep" means is the first step. There are three common behaviours you’ll hit: display-off (screen off, CPU awake), suspend/S3 (RAM powered down, CPU stopped), and hibernation/S4 (RAM contents saved to disk and nearly everything off). If a machine is in S3 or S4 it won't accept an incoming connection unless you wake it first. Display-off alone usually still allows remote connections, because the OS and network stack remain running.

For remote desktop you need either: the machine stays responsive (no S3/S4), or a way to wake the machine (Wake-on-LAN or scheduled wake). Picking the right pattern depends on power, hardware, and security requirements.

Two practical patterns: keep-awake vs wake-on-demand

There are two realistic approaches used in production:

• Keep-awake (prevent sleep): the machine never enters deep sleep while you need remote access. This is simple, reliable and good for dedicated workstations or short sessions. Downsides: higher power use, possible wear, and you must manage assertions across reboots and updates.
• Wake-on-demand (Wake-on-LAN / scheduled wake): let the machine sleep and wake it remotely when needed. This is power-efficient and preferred for rarely-used targets or geographically distributed fleets — but it requires WOL-capable hardware, router support for Wake-on-WAN, or a relay service that can send magic packets from outside your LAN.

In my experience: for a daily-use dev workstation, keep-awake is less friction. For servers or lab machines you rarely touch, WOL is the right call.

OS recipes: concrete commands you can use

Below are tested, version-neutral commands and tactics for each OS. These examples are safe to copy-and-run; read the notes for permanence and security tradeoffs.

Windows (10 / 11)

Quick checks and commands:

powercfg /requests            # see what is currently preventing sleep
powercfg /devicequery wake_armed  # devices allowed to wake the PC
powercfg /lastwake            # why the PC last woke

Disable automatic sleep on AC (keeps machine awake while plugged in):

powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 10  # keep display off but system awake

Enable Wake-on-LAN:

• Open Device Manager → your NIC → Power Management and check Allow this device to wake the computer and optionally Only allow a magic packet to wake the computer.
• Confirm BIOS/UEFI has Wake-on-LAN enabled.

Preventing sleep in a script (short term): use a small PowerShell loop that performs a harmless periodic operation, or create a scheduled task that runs while you need the machine awake. For example, a persistent keep-alive process that runs in the user session:

while ($true) { Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.Cursor]::Position = [System.Drawing.Point]::new(0,0); Start-Sleep -Seconds 300 }

That technique is useful for ad-hoc sessions but is a hack — prefer configuring power plans centrally for managed machines.

macOS (Ventura and later)

macOS offers two pragmatic tools: pmset for persistent changes and caffeinate for session-level assertions.

# prevent system sleep while on AC (persistent)
sudo pmset -c sleep 0

# keep the system awake temporarily for 1 hour
caffeinate -i -t 3600

Notes: pmset changes persist across reboots until you revert them. caffeinate is handy for short remote sessions or wrapper scripts; it doesn’t change system defaults. If you need the machine awake with the lid closed, Apple officially only supports this for external displays or specific hardware — closing a laptop lid still enters sleep on most models unless using approved clamshell modes.

Linux (systemd-based distros)

On modern Linux, systemd-inhibit is the convenient tool to block sleep for a running process. Example:

# block sleep while a shell session runs
systemd-inhibit --why='remote desktop session' --mode=block bash -c 'while true; do sleep 60; done' &

For GNOME desktops you can adjust power settings per-session or with gsettings, for example:

gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
# revert with: 'suspend' or another choice

System-wide changes can be managed via /etc/systemd/logind.conf (HandleLidSwitch=ignore) or desktop power profiles, but these require caution — changing lid-switch behaviour affects physical security and thermal limits.

Wake-on-LAN and network considerations

WOL sends a magic packet to a NIC to wake the machine. Two common problems block it: BIOS/UEFI not enabled and network equipment losing ARP state after the machine sleeps.

• Enable WOL in BIOS/UEFI and in the OS network adapter settings.
• On Windows, confirm with

  powercfg -devicequery wake_armed

  .
• Test sending a magic packet locally with Linux's wakeonlan MAC or with tools like wolcmd on Windows.

Wake-on-WAN (waking across the internet) adds router or relay complexity: you either port-forward UDP to the broadcast address (not supported on all routers), use a persistent device inside the target LAN to forward a magic packet, or use a cloud/relay service that can send the packet from outside the network.

If Wake-on-WAN is needed, read our detailed setup guide: Remote Desktop Wake on LAN: Setup and Troubleshooting. For cases where port-forwarding isn’t desirable, see Remote Desktop Without Port Forwarding Explained for alternate patterns.

Using Tenvo: relay vs self-hosting, and the security tradeoffs

Operationally, the easiest option is to use Tenvo's managed relay. Tenvo provides native clients for Windows, macOS and Linux, a browser client in public beta, and a multi-region managed relay by default. Plans are Free $0, Lite $2.99/mo and Pro $7.99/mo. The managed relay removes the need to set up complicated Wake-on-WAN routes or maintain uptime for your own relay nodes.

Honest security note: Tenvo uses TLS with a per-device certificate. When two endpoints connect directly (peer-to-peer), TLS is end-to-end between those devices. But when a session falls back to a relay, TLS terminates at the relay — the relay operator can access the session data. If organizational policy forbids third-party relays, self-hosting is the right call only when you have a written requirement that forces it (compliance, isolated networks, data residency). Self-hosting shifts the burden of patching, key custody and certificate renewal to you and can cost more once on-call time is counted. See Is Remote Desktop Secure? An Honest Threat Model to understand the tradeoffs in detail.

If you want to keep machines asleep and still connect reliably without exposing WOL to the internet, Tenvo’s managed relay can be used to deliver wake signals from the cloud into your LAN if you run a small, trusted relay or bridge inside the network. That’s a practical middle ground versus opening router ports.

Troubleshooting: what to check when remote desktop sleep mode still blocks you

Checklist for diagnosing unreachable targets:

• Is the machine actually asleep? Check uptime or last wake logs: Windows powercfg -lastwake, Linux journalctl -b | grep -i wake, macOS pmset -g log.
• If it sleeps immediately after you leave, look for conflicting power assertions: Windows powercfg /requests.
• For WOL, confirm NIC supports magic-packet-only wake and that device power management permits wake-up.
• For Wake-on-WAN, verify router ARP/port-forwarding behaviour; many SOHO routers drop broadcasts from WAN. A small persistent internal helper (Raspberry Pi) that accepts an authenticated request and sends a local magic packet is a robust pattern.

Monitoring and automation tips: add a lightweight heartbeat process that logs the machine's last activity to a central place (syslog, Influx, or an internal healthcheck URL). For fleets, use configuration management to apply consistent power profiles rather than relying on per-machine scripts.

When to choose each approach — quick decision guide

• Daily interactive workstation: prevent sleep (system-level power plan or caffeinate) so you can reconnect instantly.
• Infrequently used lab server: use Wake-on-LAN with a local forwarder; avoid keeping thousands of machines awake.
• Remote users spread across locations with no central network control: rely on a managed relay (Tenvo) and keep-awake for critical machines; self-host only if a written compliance requirement forces it.

For a broader setup checklist and initial configuration, see How to Set Up Remote Access in 60 Seconds.

Wrapping up: there’s no one-size-fits-all. Keep-awake patterns are simple and reliable for machines you use frequently. Wake-on-LAN is the power-efficient choice when hardware and network conditions allow. And if you need the lowest-effort cross-network option, Tenvo’s managed relay gets you working reliably — with the tradeoffs noted above.

If you want a copyable reference: use the Windows and macOS commands above for short-term sessions, configure WOL in BIOS and OS for unattended wake, and add a small internal relay or use Tenvo’s managed relay for Wake-on-WAN scenarios. Download Tenvo clients and get started at /download.