ToDesk 固定密码功能如何设置？远程开机是否支持及具体配置步骤是什么？

一、先把问题拆开：固定密码解决“连得上”，远程开机解决“开得了”

远程办公常态化之后，ToDesk 固定密码几乎成了每一台长期被控设备的标配——它免去了每次连接都要向对方索取临时验证码的往返。但真正让人卡住的往往不是密码本身，而是紧随其后的第二件事：机器已经关机，远程还怎么连得上？于是“远程开机支不支持、怎么配”，便顺理成章地成了同一条工作流里的下一个问题。

这两件事必须分开看。固定密码属于认证层的配置，改的是“谁能连进来、用什么凭证连进来”，全部在软件内完成；远程开机属于供电与固件层的能力，取决于主板、网卡、路由器和操作系统的配合，ToDesk 在其中扮演的是“发令者”而非“执行者”。把这两层混为一谈，是绝大多数配置失败的起点——后面那些“明明设了却没反应”的疑问，根源大多埋在这里。

因此本文的组织方式是一条工程路径：先说明每个功能真正解决什么问题、边界在哪里（问题与约束），再给出各平台的最短操作路径（解法），最后用验证步骤和故障排查表确认它是否真的生效。读完之后，你应该能判断自己这台机器“该不该配远程开机”，而不只是“会不会配”。

二、固定密码的定位：它替代的是“临时验证码”，不是账号体系

在 ToDesk 的安全设置里，被控端通常提供两类连接凭证：一类是每次刷新都会变化的临时密码（部分版本界面称为“临时密码”或“随机密码”），适合一次性协助、装机、临时排障；另一类是可以自行设定的固定密码，部分客户端版本在界面上显示为“安全密码”或“固定密码”。名称可能随版本调整，请以你实际安装的客户端界面文案为准——判断依据是“是否需要手动设定并长期保留”，而不是这几个字怎么写。

两者的取舍非常清晰。临时密码的优势在于泄露窗口极短——你把六位数字念给同事，协助结束后刷新一次，之前的凭证即失效；代价是它不适合无人值守的场景，比如家里的台式机、办公室的工作站、机房里那台只跑数据库的机器。固定密码的价值恰恰在于“不需要有人在旁边念数字”，而它付出的代价，是凭证的暴露窗口从几分钟拉长到“你主动修改之前”。

2.1 它与“设备列表授权登录”不是同一件事

很多用户会把固定密码和“账号登录后从设备列表直接发起连接”混淆。后者走的是账号体系：你在两端登录同一账号，设备进入列表，连接时由账号身份完成校验，通常不再逐次输入设备密码。固定密码则是设备维度的独立凭证——即使对方没有登录你的账号，只要知道设备代码和这串密码，仍然可以发起连接。

这个区别决定了两条不同的安全策略：如果你的被控设备都在自己账号下，重点应放在账号本身的保护（强密码、二次验证、登录设备管理）；如果你需要把设备分享给外部同事或客户，固定密码才是那个需要被单独管理、定期轮换的凭证。把两者混用，往往会出现“账号被盗却以为改了设备密码就安全”的误判。

2.2 一个具体的取舍例子

设想一个三人小团队，运维同事需要随时接入办公室那台常开的 Windows 主机处理告警。若使用临时密码，每次都要有人到机器前（或通过另一台已连设备）读出当前密码，夜间告警时几乎不可行。改用固定密码后，接入流程从“找人要码”变成“直接连接”，单次处置时间明显缩短——这是经验性观察，具体节省多少取决于你们的响应流程。

但同一台机器如果还会被外包人员临时使用，那么固定密码就不该无差别分发。更稳妥的做法是：对内部固定成员启用固定密码并纳入密码管理器，对外部人员一律使用临时密码，协助结束后刷新。这条规则的实质，是把“凭证发给谁”和“设备由谁负责”绑在一起考虑，而不是让所有人共用一套凭证。

三、桌面端设置固定密码的最短路径

下面给出的路径以当前主流桌面客户端为参照。由于 ToDesk 的界面在不同版本中会有微调，如果菜单名称对不上，请优先在“设置”中寻找与“安全”相关的分组，而不是逐级背路径——分组语义比具体层级更稳定。

3.1 动手前的三项确认

• 确认你操作的是“被控端”：固定密码设置在被控设备上，而不是主控设备。很多人坐在自己的笔记本上找半天，其实要设的是那台远端主机。
• 确认客户端已登录且在线：未登录状态下部分安全项不可编辑，这是常见的“设置项灰掉”的原因。
• 确认你有系统权限：在受管的企业终端上，安全设置可能被策略锁定，此时需要联系设备管理员而不是反复重装。

这三条确认对应的正是后文故障排查表里最靠前的两类现象，提前排除能省下不少来回。尤其第一条，方向错了之后，在错误的机器上无论怎么设置都不会生效。

3.2 Windows 与 macOS 的操作步骤

1. 在被控电脑上打开 ToDesk 客户端，登录你的账号。
2. 进入“设置”（部分版本位于主界面右上角齿轮图标），找到“安全设置”分组。
3. 定位到固定密码/安全密码一栏，选择“设置”或“修改”按钮。
4. 输入符合强度要求的新密码并确认。界面通常会给出强度提示，弱口令会被拒绝。
5. 保存后，回到主界面确认设备代码与“使用固定密码连接”的状态已经生效。

macOS 端的整体流程与 Windows 一致，差异集中在系统权限层：首次设置某些安全项时，系统可能弹出授权窗口要求输入本机管理员密码。这是 macOS 的常规保护机制，不是 ToDesk 额外增加的步骤，按提示授权即可。

3.3 Linux 端的差异与回退方案

Linux 版客户端的界面精简程度更高，安全设置项通常集中在同一面板内。如果图形界面中找不到对应入口，先确认安装的是官方发行包，而非第三方仓库的移植版本——不同发行版的打包方式可能导致功能项缺失，这属于打包差异，而非功能不存在。

回退方案很简单：若固定密码一时无法设置成功，可以先在“临时密码”模式下完成本次连接，把问题留到有物理接触机会时再处理。不要为了绕过限制去使用来源不明的修改版客户端——那会把一个配置问题升级成安全问题。

四、移动端与“只做被控”的设备该怎么配

Android 与 iOS 端的角色分工与桌面端相反：手机和平板绝大多数时候是主控端，用来连别人；只有在“手机被远程协助”这种场景下，才需要设置被控凭证。Android 端受系统限制，被控能力与具体机型、系统版本强相关，部分厂商 ROM 会限制后台常驻，导致固定密码虽然设了却连不上——这时问题不在密码，而在进程没能活到连接发起的那一刻。

最短路径是：在手机端打开 ToDesk → 进入“我的/设置” → 找到安全相关分组 → 设置被控密码。iOS 由于系统限制，通常不作为被控端使用，因此这一项在 iOS 上可能不可见或受限，这属于平台能力边界，不是配置错误。

五、固定密码的强度取舍：能连上，比记得住更重要

固定密码一旦设定，通常长期不变，这意味着它的强度直接决定了暴露窗口内的风险水平。现实中常见的错误做法是用生日、手机号后六位，或者“公司名+123”这类可推测组合。远程控制软件的被控端一旦被陌生连接进入，后果不是“看到几个文件”这么轻——对方拿到的是一台完整桌面的操作权。

更务实的做法是把它当成一个独立账号来管理：使用密码管理器生成并保存，长度不少于十几位，混合大小写与符号；或者用一句只有你自己知道来源的长短语做基础，再做少量变形。这样做的代价是“记不住”，但密码管理器或手机端的加密笔记可以解决这一点，而泄露的代价无法用记忆便利来对冲。

5.1 什么时候该主动轮换

不建议设置固定的轮换周期（那容易变成形式主义），而是按事件触发：有成员离职或退出协作、密码曾经通过聊天工具明文发送过、设备曾送修或重装、发现异常连接记录。这四类事件之后，改一次密码的成本远低于事后排查。

验证是否发生过异常连接，可以查看客户端的连接记录/日志入口（不同版本位置略有差异）。预期可观测的结果是：每条记录包含时间与来源标识，若出现你不认识的时间段连接，就应当立即改密码，并检查设备是否被加入了陌生账号的设备列表。

六、远程开机到底支不支持：先回答三个前提

这是本文最需要克制表述的部分。结论是：ToDesk 提供与远程开机相关的能力与配套方案，但它不能凭空把一台不具备条件的机器唤醒。是否可用，取决于硬件、网络、软件三方面同时满足，缺一不可。具体的功能入口名称与可用范围，请以你当前安装的客户端及官方页面说明为准。

6.1 硬件前提：主板与网卡是否支持网络唤醒

远程开机在消费级设备上最通用的技术基础是 Wake-on-LAN（简称 WOL，即网络唤醒）：网卡在主机关机后仍保持低功耗供电，收到特定格式的“魔术包”后触发开机。它要求主板 BIOS/UEFI 中存在相关选项并已启用，网卡支持并在系统中开启唤醒，且关机后网卡仍能取电。台式机通常具备这些条件；笔记本则要看厂商是否保留该选项，很多轻薄本为了省电默认关闭，甚至不提供。

6.2 网络前提：魔术包能不能送到那台机器

WOL 的本质是一个广播包，天然限制在同一个二层网络内。跨网络（比如在咖啡厅唤醒办公室主机）就需要额外安排：路由器上的端口映射、静态 ARP 绑定，或者使用厂商提供的硬件中转方案。这一步是失败率最高的环节——很多人在 BIOS 里配好了，最终卡在路由器不支持定向广播转发。

6.3 软件前提：客户端里那条链路是否打通

软件层要解决的是“谁来发这个包、发给谁”。ToDesk 的相关方案大致分为两类：一类是在同一局域网内通过客户端触发唤醒；另一类是借助配套的远程开机硬件，由硬件代为发出唤醒信号，从而绕开路由器配置的复杂度。两条路径的适用条件不同，下一节展开。换句话说，前两个前提回答的是“这台机器能不能被唤醒”，第三个前提回答的是“由谁按下这个键”。

七、两条实现路径：局域网 WOL 与配套硬件

7.1 路径 A：局域网内 Wake-on-LAN

适合场景：被控主机与主控端处于同一局域网，或者你能在路由器上做端口映射与 ARP 绑定。典型例子是家庭用户从卧室的笔记本唤醒书房的主机，或小公司内网里从一台常开设备唤醒另一台。

优点是零额外硬件成本，全部依赖已有设备；缺点是配置项分散在 BIOS、操作系统、路由器三处，任何一处遗漏都会导致“按了没反应”。此外，公网环境下的安全性需要额外评估——把唤醒端口暴露到公网本身就是一个风险点，应尽量配合访问控制。

7.2 路径 B：配套远程开机硬件

适合场景：被控主机所在网络无法做端口映射（例如公司网络由 IT 统一管理），或者用户不具备路由器配置能力。这类方案通常需要在被控主机所在网络中串接一个硬件设备，由该设备保持在线并代为触发开机。

它的代价是额外的采购与部署成本，收益是把“跨网络唤醒”从一个网络工程问题降级为一个设备配对问题。是否值得，取决于你被唤醒的频率：一个月只用一次的场景，硬件投入的性价比并不高；每天都要远程开机的工作站，则明显划算。具体支持的硬件型号与购买渠道，请以官方页面为准，不要依据第三方转述下单。

八、远程开机的具体配置步骤

下面按从底层到上层的顺序排列。顺序很重要：先固件，再系统，最后软件。反过来做，你会在软件里反复看到“设备离线”却不知道问题出在哪一层。

8.1 第一步：BIOS/UEFI 侧

重启被控主机，按厂商指定按键（常见为 Del、F2 或 F10，因品牌而异）进入固件设置。在电源管理或高级设置分组中寻找与网络唤醒相关的选项，名称通常包含 Wake on LAN、Power On by PCI-E、Resume by LAN 等字样。启用后保存退出。

需要注意两个边界：其一，部分主板在“ERP 就绪”或“深度节能”开启时会切断关机后的网卡供电，导致 WOL 失效——节能策略与“关机后网卡持续取电”本身相互冲突，此时应关闭该节能项；其二，少数品牌机把该选项做进了厂商定制界面甚至直接隐藏，这种情况下只能走配套硬件路径，不要在固件里死磕。

8.2 第二步：操作系统网卡侧

Windows 下的路径是：右键“此电脑”→“管理”→“设备管理器”→展开“网络适配器”→双击有线网卡→“电源管理”选项卡→勾选“允许此设备唤醒计算机”；再切到“高级”选项卡，找到 Wake on Magic Packet 一类的属性并设为启用。修改完成后可用管理员权限打开命令提示符，执行下列命令查看哪些设备已被允许唤醒：

powercfg /devicequery wake_armed

预期结果：输出列表中应包含你的有线网卡名称。如果这里为空，说明系统层尚未生效，回到设备管理器复查，而不必继续往下配置路由器。

Linux 下可用 ethtool 查看与设置网卡的唤醒标志（命令中的网卡名请按实际情况替换）：

sudo ethtool eth0 | grep Wake-on
sudo ethtool -s eth0 wol g

macOS 的路径是“系统设置”→“电池”或“节能”，勾选“唤醒以供网络访问”。但这里有一个重要的平台边界：经验性观察显示，Apple Silicon 机型在完全关机状态下通常无法被网络唤醒，实际可用的是“睡眠状态下被唤醒”。因此 Mac 用户应把预期调整为“保持睡眠而非关机”，这也是它与 Windows 台式机最大的差异。

8.3 第三步：ToDesk 客户端侧

在被控主机上打开客户端并登录账号，进入设置中与远程开机相关的分组，按界面提示完成绑定或启用。不同版本该入口的位置与名称可能不同，若当前版本未见相关选项，先升级到官方发布的最新版本再查找，不要从第三方站点下载所谓的“增强版”。

启用后建议立刻记录两项信息：被控主机的网卡 MAC 地址，以及它在目标网络中的固定内网 IP（可在路由器中做 DHCP 静态分配）。这两项是后续排查的基础，事后回想往往记不清——排查时最耗时的通常不是判断问题，而是找不到当初那串地址。

8.4 第四步：网络与路由器侧（仅路径 A 需要）

如果主控端与被控端不在同一局域网，需要在路由器上做两件事：为目标主机绑定静态 ARP（把内网 IP 与 MAC 固定关联），以及配置端口转发把唤醒包送到该地址。部分家用路由器不提供定向广播转发能力，此时该路径不可行，应改用配套硬件方案。

安全边界必须强调：把唤醒端口直接暴露到公网，等于给扫描器提供了一个可探测目标。若必须如此，应限制来源 IP、使用非默认端口，并接受“这不是一个高强度防护”的事实。对安全要求高的场景，硬件中转方案在这一点上明显更省心。

九、场景映射：三类用户该怎么组合

第一类：家庭个人用户。典型诉求是从公司或外出时连回家里那台常开主机。建议固定密码必设并纳入密码管理器；远程开机视主板支持情况决定——若机器本来就 7×24 常开，远程开机的收益接近于零，不必投入。

第二类：小团队运维。多台设备、多人轮值。建议固定密码统一管理、按事件轮换；远程开机优先考虑硬件方案，因为跨网络 WOL 的维护成本会随着路由器型号的杂乱而上升。同时应建立一份设备清单，记录每台机器的设备代码归属与密码保管人。

第三类：受管企业终端。设备由 IT 统一策略管理。此时固定密码很可能被组织策略覆盖，个人不应尝试绕过。远程开机更可能作为基础设施能力由 IT 统一提供，普通用户需要做的是提交需求，而不是自行配置。

三类场景的差异，本质上不在软件版本，而在“网络是否可控”与“设备是否长期在线”这两个变量上。先把这两个问题回答清楚，再去看具体配置项，选择会容易得多。

十、验证与观测：怎么证明它真的生效了

配置完成不等于生效。固定密码的验证方法是：用另一台设备发起连接，输入设备代码与刚设置的密码，预期是直接进入桌面而不再索要临时验证码；随后刷新被控端的临时密码，再次连接，若仍能用固定密码进入，说明设置确实独立生效。

远程开机的验证需要分两步。第一步做本地验证：在同一局域网内用另一台设备发送唤醒请求，观察被控主机是否在数十秒到数分钟内启动（时长因主板与网络环境而异，差异可能很大）。第二步做远程验证：断开到外部网络，重复同一操作。第一步成功而第二步失败，问题几乎必然在网络层，而不是固件或系统层。

建议把验证结果记录下来，形成一份属于你自己的配置档案：机器型号、固件中启用的选项名、网卡型号、MAC 地址、使用的路径（WOL 或硬件）、验证日期。这份记录在未来更换路由器或重装系统时会节省大量时间。

十一、故障排查：现象、原因、验证、处置

现象	可能原因	验证方法	处置
固定密码设置项灰掉不可点	未登录账号，或被组织策略锁定	退出重登后复查；换一台个人设备对比	登录账号；受管设备联系管理员
设了固定密码仍提示需要临时密码	连接时选择了临时密码模式，或设置未保存	重新进入设置页确认状态；换设备复测	重新保存设置；连接时选择固定密码方式
局域网内也唤不醒	固件未启用 WOL，或节能项切断了网卡供电	进入固件复查；关闭深度节能后重试	启用相关选项并保存；仍无效则确认硬件是否支持
本地能唤醒，外网不行	路由器不支持定向广播，或未做 ARP 绑定	检查端口转发与 ARP 表项是否存在	补齐网络配置；不具备条件时改用硬件方案
Mac 关机后无法唤醒	平台能力边界，Apple Silicon 关机态通常不支持	改为睡眠状态后重试	调整预期为“保持睡眠”；或接受关机态不可唤醒

这张表覆盖的是高频分支，而非全部可能。遇到表外现象时，通用的排查顺序仍然是：先分层定位（固件层、系统层、网络层、软件层），再做单点替换验证。切忌在四个层次之间来回跳跃式修改，那会让问题状态变得不可复现。

十二、不适用清单：这几种情况下别硬上

第一种，被控设备本身不常关机。远程开机的全部价值在于“从关机到可用”，如果设备本就 7×24 常开，投入配置与硬件成本换取的是一个几乎不会触发的路径，性价比很低。

第二种，笔记本且厂商未提供 WOL 选项。这类设备通常以电池续航优先，关机后网卡断电是设计取舍，不是配置缺陷。与其耗费时间刷固件、找非官方补丁，不如接受“保持睡眠+接通电源”的替代方案。

第三种，安全合规要求高的环境。把唤醒能力暴露到公网、在路由器上开放转发端口，在很多行业的合规框架下是明确不推荐的。这类环境应走统一的基础设施方案，由 IT 评估。

第四种，多人共享同一固定密码且无人负责轮换。这种配置在初期很省事，但随着人员流动会逐渐失控。如果组织内无法指定密码保管责任人，就不要启用固定密码，改用临时密码加账号授权的组合更稳妥。

十三、最佳实践检查表

把下面这份清单当作上线前的自检，逐项打勾比事后回忆更可靠。它同时适用于个人用户和小团队。

• 固定密码已设置，长度与复杂度达标，并存放在密码管理器中而非聊天记录里。
• 已明确密码保管人，并约定按事件（人员变动、明文外发、设备送修、异常记录）轮换。
• 已确认连接记录入口的位置，并知道如何识别陌生来源的连接。
• 远程开机前，已确认固件中的 WOL 选项已启用，且深度节能未切断网卡供电。
• 系统层已用 powercfg / devicequery wake_armed（Windows）或 ethtool（Linux）验证过唤醒设备列表。
• 已记录被控主机的 MAC 地址与固定内网 IP，并写入配置档案。
• 已完成一次本地唤醒验证，再做一次跨网络验证，两步分开记录结果。
• 若使用公网转发，已限制来源并接受其防护强度有限的事实；否则优先考虑硬件方案。
• Mac 用户已把预期调整为“睡眠可唤醒、关机不可唤醒”。
• 受管设备上的安全设置未擅自绕过，需求已提交给设备管理员。

清单本身不产生安全感，逐项验证过的清单才会。任何一项暂时无法确认时，宁可把它标成“待验证”，也不要凭印象打勾。

十四、常见问题（FAQ）

十五、结语：先定策略，再动配置

回到最初的问题：ToDesk 固定密码是一道软件层的认证开关，配置成本低、收益直接，几乎对所有长期被控设备都值得开启；远程开机则是一个跨硬件、跨网络的能力，是否值得投入取决于那台机器开机的频率、所在网络的可控程度，以及你愿意为一次“远程按下电源键”付出多少配置与采购成本。

如果只能记住一句话：先在纸面上画出你要连着的那台机器的日常状态——常开、常睡眠，还是会彻底关机——答案基本就出来了。常开只需配好固定密码；常睡眠可以争取睡眠唤醒；彻底关机且必须远端唤醒，才需要认真评估 WOL 或硬件方案。

下一步建议按这个顺序动手：先在客户端里把固定密码设好并用第二台设备验证一次，再进入固件与系统层确认唤醒能力，最后才处理网络与路由器。每完成一步就记录结果，出问题时你至少有据可查，而不是在一堆可能的变量里凭记忆试错。

还需要留一点预期管理：客户端的界面文案、菜单分组与入口位置会随版本迭代持续调整，因此更值得记住的是“认证层与供电层分离”这个结构，而不是某一条具体路径。功能范围与命名仍以官方发布说明和你实际安装的客户端界面为准；本文提供的是判断方法与验证顺序，具体按钮以屏幕上的那一处为准。