授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、一条命令停不下来先分清是哪一件事1.1 事情往往是这样开始的你敲了一条命令屏幕上开始往外滚东西或者干脆什么都不动只有光标在那儿等着。你觉得不对劲按下了中断组合键。有时候一次就回来了提示符重新出现有时候你按了三四次屏幕还是老样子。更让人迷惑的是同一条命令、同一个终端昨天按一次就回来今天怎么按都没用。还有另一种情形你直接关掉终端窗口以为事情就这样结束了。过了一会儿新开一个终端去看发现之前那个东西还在跑。这几种现象嘴上说的都是停不下来可它们落在不同的位置上。第一种是你发出的信号到底给了谁、对方有没有理它第二种是发信号的那个源头终端走了之后作业被怎么处置。本文讲的是前一层信号与前台进程。1.2 分流只需要三个问题分流不需要复杂工具三个问题就够。第一个问题按键之后命令本身有没有变化如果它停了说明信号送到了而且被当成了要处理的事如果它毫无反应那要问的就是——信号没送到它手里还是它收到了却选择不理。这两个原因的解释完全不同。第二个问题你按了几次一次就回来和按好几次才有反应看起来是两个毛病其实是同一件事的两面。原因在第三章和第四章。第三个问题终端窗口是不是被你关掉了如果是那走的根本不是按键这条路而是第五章要讲的另一条路。这三个问题各自对应一个只读动作。⚠️代码待验证ps# 只读看当前这个会话下有哪些进程dockerps# 只读看容器列表以及它们各自当前的状态两条都只做看这一件事不启动、不停止、也不改任何配置。你看到的现象更可能落在哪一层本文的哪一章按键之后命令停了提示符回来了信号送到了而且被当成要处理的事第三章、第四章按了好几次命令还在跑信号到了但接收方自己接管了它第四章关掉终端之后它居然还在跑终端退出与作业被如何处理第五章容器停不下来过几秒才停容器的停止信号与宽限期第六章1.3 本文只讲控制层先把范围说清楚。本文的观察对象是控制层你怎么把一件事停下来以及停下来这个动作到底发给了谁。有几件事本文不写不写怎么强行终止别人的进程不写进程注入这一类话题也不展开容器的资源限制与内存那一层。文中出现的每一条命令都只做看这件事。二、中断组合键发出的是哪个信号2.1 一个键一个信号按下中断组合键之后终端做的事不是把那条命令关掉而是发出一个信号。这一点是所有后续讨论的前提按键本身不等于停止按键只是把一封信寄出去。这封信叫什么名字官方手册写得很直接。Bash 官方手册在讲信号的那一节里描述这个信号来源时用的措辞是usually generated by ^C——也就是说中断组合键产出的信号就是SIGINT。那么停下来这个动作是谁做的是收到信号的那个进程自己做的。信号到了它手上它可以按默认方式对待对SIGINT来说默认就是终止自己也可以自己接管、决定不终止。所以按了键和停下来了之间从来不是等号。2.2 shell 自己对这些信号的态度还有一个容易被忽略的角色shell 本身。你在终端上敲的那个键最终是终端把信号发给了一批进程而 shell 在不在这批进程里取决于下一章要讲的进程组归属。同时shell 收到某些信号时也有自己的默认态度。官方原话是逐字引用When Bash is interactive, in the absence of any traps, it ignores SIGTERM (so that ‘kill 0’ does not kill an interactive shell), and catches and handles SIGINT (so that the wait builtin is interruptible). When Bash receives a SIGINT, it breaks out of any executing loops. In all cases, Bash ignores SIGQUIT.这段话里含三件事逐条拆开看第一交互式 shell 忽略SIGTERM你在终端里冲着这个 shell 发SIGTERM它不会因此退出官方还给这条设计配了理由——为了不让kill 0把交互式 shell 干掉。第二交互式 shell 会接住并处理SIGINT目的是让wait这个内建命令可以被中断它收到SIGINT之后会跳出正在执行的循环。第三在任何情况下Bash 都忽略SIGQUIT。官方用的是In all cases没有留例外。截至 2026-09-27官方手册这一节对交互式 shell 的口径就是上面这三句。信号名交互式 Bash 的默认态度官方依据逐字要点本文位置SIGTERM忽略it ignores SIGTERM (so that kill 0 does not kill an interactive shell)本章SIGINT接住并处理收到后跳出正在执行的循环catches and handles SIGINT (so that the wait builtin is interruptible)本章SIGQUIT在任何情况下都忽略In all cases, Bash ignores SIGQUIT.本章SIGHUP默认退出The shell exits by default upon receipt of a SIGHUP.第五章2.3 信号名从哪里来信号是一组带名字的东西kill -l这个动作的作用就是把信号名列出来。本文只把它是一个列出信号名的动作这件事放在这里不贴它列出的内容——本批一律不贴终端里的原始输出。⚠️代码待验证kill-l# 只读列出信号名不发送任何信号也不改变任何东西有一点要单独说清楚kill -l只是看名字它自己不发信号、不结束任何进程。名字和编号的对应关系请以你自己系统上的手册为准本文不列任何编号对照表讨论范围只涉及五个名字SIGINT、SIGTERM、SIGKILL、SIGQUIT、SIGHUP。三、键盘信号到底发给了谁3.1 未启用作业控制同一个进程组这是全文最硬的一条也是为什么有时按一下就回来了、有时按好几次也没用的根子。官方原话逐字引用the shell receives keyboard-generated signals such as SIGINT (usually generated by ‘^C’) that users commonly intend to send to that command. This happens because the shell and the command are in the same process group as the terminal, and ‘^C’ sends SIGINT to all processes in that process group.把这段翻成要点是三层意思第一你在终端里按下中断键时这个信号的收件人不是你以为的那一个进程而是终端那个进程组里的所有进程。第二之所以这件事会顺带打到 shell 身上是因为未启用作业控制时shell 和它正在跑的那条命令处在同一个进程组里——也就是与终端相关联的那个进程组。第三官方对这句话的用途也说得很明白用户的本意是把这个信号发给那条命令但因为两者同组shell 也跟着收到了。这解释了一个很日常的现象——你按中断键的时候那条命令停了命令行会话有时候也会跟着顿一下。3.2 启用作业控制shell 不在那个进程组里那么为什么有时候感觉又不一样了因为 shell 到底在不在那个进程组里是会变的。官方对另一种情形的表述是逐字引用the shell does not receive keyboard-generated signals, because it is not in the same process group as the terminal.启用作业控制之后shell 把自己移出了与终端关联的那个进程组于是键盘产生的信号打不到它身上。信号还是照发只是那份收件名单里没有它了。两种情形并排看就是下面这张表情形shell 在不在终端那个进程组里键盘信号发给谁shell 会不会收到未启用作业控制在该进程组里的所有进程会收到启用作业控制不在该进程组里的进程不含 shell不会收到这张表解决了本文开头那个困惑的前一半你按下的每一次信号都发出去了但到底有几方收到取决于当时谁和谁在同一个组里。3.3 为什么这件事对排障有用这一章的价值不在于记住进程组这个词而在于改掉一个默认假设你在终端里按键不是你直接对那条命令说话而是往一个组里广播了一封信谁收到、谁理它是接收方自己的选择。所以当你发现我按了它没停的时候第一条判断不是我按得不够用力而是这封信到了它手上没有以及它收到之后做了什么。后半个问题就是下一章。⚠️代码待验证ps# 只读看当前会话下有哪些进程以及它们各自的归属信息本文不给怎么改进程组归属的示范动作——那属于改环境的操作不是看。四、命令结束之后shell 的两条判断4.1 未启用作业控制时shell 还要再判一次前两章讲了未启用作业控制时shell 和命令在同一个组里所以 shell 自己也收到了那个信号。既然收到了shell 该怎么做官方说它会等前台命令先结束然后做判断判断的依据是这条命令是怎么结束的。于是就有了两条路。第一条路命令确实是因为这个信号而结束的。官方原话逐字引用If the command terminates due to the SIGINT, Bash concludes that the user meant to send the SIGINT to the shell as well, and acts on the SIGINT意思是既然命令是被SIGINT终止的Bash 就认为你本来也想让 shell 收到这个信号。走这一条路你按一次键命令停了shell 也按收到SIGINT的方式动作——所以提示符干脆地回来了。第二条路命令不是因为这个信号而结束的。官方原话逐字引用If the command does not terminate due to SIGINT, the program handled the SIGINT itself and did not treat it as a fatal signal. In that case, Bash does not treat SIGINT as a fatal signal, either…意思是如果命令没被这个信号干掉那就说明这个程序自己接管了这个信号并且不把它当成会要命的信号。这种情况下Bash 也不把它当成会要命的信号。官方在这里举了一个很具体的例子编辑器会把SIGINT当成一个普通操作来处理比如中止一条正在进行的编辑命令而不是退出程序本身。4.2 这就解释了按了没用把这两条路放在一起那个困惑就解开了。你按下中断键信号发到了整个进程组里前台那个程序收到了。接下来往哪条路走取决于这个程序自己愿不愿意停它愿意停命令结束Bash 判定你也想让 shell 停shell 跟着一起动作它自己接管了这个信号、并且不认为这个信号要命它就会继续跑Bash 也跟着不把它当回事。所以按好几次才有反应这件事多数时候不是信号没送到而是接收方每一次都选择了自己处理。你按多少次它就自己处理多少次只有当它处理到某个边界、真的退出了这个循环才结束。还要补一个前提这条判断是未启用作业控制时的逻辑。启用作业控制时shell 根本不在那个组里、收不到键盘信号也就谈不上跟着一起停。命令结束的方式Bash 的判断你看到的结果命令因该信号而结束认为你也想把这个信号发给 shell并且照做命令停shell 也跟着动作命令没因该信号结束程序自己处理了它不把这个信号当成会要命的信号命令继续跑看起来像按了没用⚠️代码待验证信号送到了 和 对方停下来了 是两件事判断顺序是 1. 这个信号发出去了吗——按键这个动作本身就发出去了。 2. 谁收到了——取决于当时谁和谁在同一个进程组里第三章。 3. 收到的人怎么处理它——它自己说了算这就是本章的两条分岔。五、关掉终端窗口之后SIGHUP 与 disown5.1 shell 收到 SIGHUP 就退出前面几章讲的是按键这条路。还有一条路是终端本身没了你关掉终端窗口或者连接断开了。官方对 shell 在这种情况下的行为写得很明确逐字引用The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.两句话两个要点。第一shell 收到SIGHUP时默认行为就是退出。第二也是最容易让人意外的一点在退出之前交互式 shell 会把这个SIGHUP再发一遍给它手上的所有作业不管这些作业是正在运行的还是已经停下的。也就是说关掉终端这件事不是只管 shell 自己它会顺手把信号转发出去。这一条正好解释了本文开头那个现象。你以为关掉窗口就等于结束了其实这条链是这样的终端没了 → shell 收到SIGHUP→ shell 决定退出 → 退出之前先把SIGHUP转发给它带着的那些作业。至于每个作业收到之后停不停仍然回到第四章那个问题——它自己怎么处理这个信号。5.2 让某个作业不收到它既然默认是转发给所有作业那自然会有一个反过来的需求我不想让某个作业收到这封信。官方给的答案是disown——把这个作业从作业表里移出它就不会被转发到了。这里要分清的是disown处理的是要不要把它算在我的作业里这件事而不是给它发一个停止信号。它本身不是一种停下来的动作它改变的是一份名单。5.3 交互式 shell 对 SIGTERM 与 SIGQUIT回到第二章那张表把两种外来信号再对一次交互式 shell忽略SIGTERM理由是为了不让kill 0把交互式 shell 干掉并且在任何情况下都忽略SIGQUIT。这两条合起来能回答一个常见的疑问“我在终端里冲着 shell 发一个终止信号它怎么不退出”——因为这是它有意为之的默认态度不是它坏了。要让它走走的是另一条路终端退出带来的SIGHUP。情形默认行为官方依据逐字要点交互式 shell 收到SIGTERM忽略it ignores SIGTERM (so that kill 0 does not kill an interactive shell)交互式 shell 收到SIGQUIT在任何情况下都忽略In all cases, Bash ignores SIGQUIT.交互式 shell 收到SIGINT接住并处理catches and handles SIGINT交互式 shell 收到SIGHUP默认退出退出前把SIGHUP转发给所有作业运行中的与已停止的The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.想让某个作业不被转发到用disown把它从作业表里移出同上下面这份资料把信号发给谁、谁理它、终端退出之后作业怎么办这三段整理成了一页和本章的对照表呼应配套资料把信号归属、两条判定、终端退出整理成一页对照表放在资料包里扫码即可获取六、容器这一侧docker stop 之后为什么要等几秒6.1 默认先 SIGTERM宽限期后才 SIGKILL前五章讲的是你在终端里跑东西。容器里的程序是另一套入口但问的是同一个问题停下来这个动作到底发给了谁、发的是什么。Docker CLI 对docker container stop的说明是逐字引用The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. The first signal can be changed with the STOPSIGNAL instruction in the container’s Dockerfile, or the --stop-signal option to docker run and docker create.拆成三层看第一先发给容器里的主进程一个SIGTERM。注意是主进程——容器里往往有好几个进程在跑先收到这封信的是被指定为主进程的那一个。第二宽限期过去之后再发SIGKILL。官方在另一句里把这件事说得更直逐字引用If the container does not exit after the timeout elapses, it’s forcibly killed with a SIGKILL signal.也就是说宽限期是给它一个自己收尾的机会这个机会用完了它还没退才走强制结束那一手。这就回答了本文开头那个问题docker stop之后为什么要等几秒——那几秒不是命令卡了而是它本来就在等等主进程自己把收尾做完。第三第一封信的名字是可以换的换的地方有两个镜像里的STOPSIGNAL或者启动时的--stop-signal选项。6.2 默认是几秒以及这个数到底从哪来关键的一句在这里逐字引用If no default is configured for the container, the Daemon determines the default, and is 10 seconds for Linux containers, and 30 seconds for Windows containers.这句话里有一个极容易被略过去的条件“如果没有为容器配置默认值”。也就是说这个数不是容器自己带来的而是在容器没有自带配置的时候由守护进程来决定。截至 2026-09-27官方这一页给出的守护进程口径是Linux 容器 10 秒Windows 容器 30 秒。为什么要强调默认值从哪来因为它直接决定排障的下一步。你看到等了十来秒才停不一定说明这条命令写死了 10 秒而可能是这个容器没有自己的配置、落到了守护进程的默认上。要确认走的是哪一条默认就得看容器本身有没有配过。6.3 信号与宽限期怎么改官方对这两个开关的说明是逐字引用--signalSignal to send to the container--timeout/-tSeconds to wait before killing the container两条合起来就是这一章的全部机制一个开关决定第一封信叫什么名字另一个开关决定等多久。宽限期这个数由超时参数给出官方在这一页写作--timeout简写-t在不同入口下它也可能写作--stop-timeout具体以你所用入口的文档为准。而等多久还有一个特殊取值逐字引用If you set --timeout to -1, no timeout is applied, and the daemon waits indefinitely for the container to exit.设成-1就是不设时限守护进程会一直等下去等到容器自己退出为止。这一条用的时候要留意它不是一个更快停下来的设置而是一个不再走强制那一手、愿意一直等下去的设置。你观察到的现象对应的机制官方依据逐字要点docker stop之后等了几秒才停宽限期到了才走强制结束after a grace period, SIGKILL等待的时间大约是十来秒Linux 容器容器没配默认值由守护进程决定If no default is configured for the container, the Daemon determines the default想换第一封信的名字镜像的STOPSIGNAL或--stop-signalcan be changed with the STOPSIGNAL instruction ... or the --stop-signal option想改等待时长宽限期参数--timeout/-tSeconds to wait before killing the container想不设时限、一直等把超时设为-1no timeout is applied, and the daemon waits indefinitely6.4 只读地看一眼容器现在是什么状态⚠️代码待验证dockerps# 只读看容器列表与当前状态dockerinspect容器名# 只读看这个容器自身的配置里有没有覆盖默认值docker inspect在这里的用处就是回答 6.2 那个问题这个容器的默认值是不是没配。没配时间就来自守护进程配过就是配置里写的那一条。本文不给停止容器的示范动作——这里只讲停下来这个动作的语义。七、把这一层变成动作7.1 三个只读动作第一步先看东西还在不在。⚠️代码待验证ps# 只读看当前会话下还有哪些进程dockerps# 只读看容器列表和它们当前的状态这一步回答的是分流里的第一个问题。重点不是看它跑得好不好而是先确认它在不在。第二步看它有没有自己的配置。⚠️代码待验证dockerinspect容器名# 只读看容器自身的信号与超时相关配置有没有被改过dockerversion# 只读确认你在跟哪一个客户端与守护进程打交道第二步回答的是第六章那个默认值从哪来的问题没配过才是守护进程的默认。而docker version用来确认你面对的是哪一个守护进程——同一台机器上装了两个环境时这一步能省掉很多绕路。7.2 现象到动作的对照表把前面几章的判断收成一张表出问题时按行对号现象更可能落在哪一层先做哪个只读动作按中断键命令停了信号送到了而且被当成要处理的事看它是否已经不在进程列表里按了好几次命令还在跑接收方自己接管了这个信号先确认它是不是本来就这么设计别再重复按键关掉终端之后它还在终端退出与作业被如何处理看还有哪些进程活着再考虑disown这类名单调整docker stop之后等了几秒容器的宽限期看这个容器有没有属于自己的默认值配置对 shell 发终止信号它不理交互式 shell 有意忽略SIGTERM不用重试这就是它的默认行为这张表只需要记住一句先判断信送到了没有和对方理不理再决定要不要做别的动作。7.3 一页自检表与三条可带走的动作出问题的时候先把下面这张自检表过一遍检查项为什么查它在哪一层我按的是哪一类键不同的键产出不同的信号名信号来源当时 shell 在不在同一个进程组里决定 shell 会不会也收到这封信进程组归属命令是被告知结束的还是自己收尾的决定 shell 下一步跟不跟着停两条判定终端是不是没了SIGHUP走的是另一条路终端退出这个容器有没有配过默认值没配过这个数就来自守护进程容器侧我想做的动作是不是强行结束别人不在本文范围也不该做边界三条可以带走的动作先分清是没送到还是不理会按键这个动作每次都会把信号发出去差别在接收方。容器侧先看配置有没有被覆盖没被覆盖走的才是守护进程的默认。不要靠重复按键来解决问题重复按解决不了接收方自己的选择。本文的使用限制所有命令均为待验证本文写作环境没有可用的 docker 环境文中每条命令都没有实际运行过参数写法与默认行为请以各自官方文档为准。本文不写任何命令的输出文本kill -l只作为列出信号名的动作出现本文不列它列出的内容也不列任何信号编号对照表。本文不给可照抄的停止示范不写怎么强制结束进程不写进程组归属怎么改。其它层不在本文范围容器的资源限制与内存那一层另有专文本文只讲信号与时序。把这一层的判断顺序整理成一页放在资料里和本章的自检表呼应配套资料把分流、看配置、别重按三步和上面这张自检表合成一页放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表#事实照口径一手出处 URL核验日期本文位置1官方原文When Bash is interactive, in the absence of any traps, it ignores SIGTERM (so that ‘kill 0’ does not kill an interactive shell), and catches and handles SIGINT (so that the wait builtin is interruptible). When Bash receives a SIGINT, it breaks out of any executing loops. In all cases, Bash ignores SIGQUIT.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 2、5 章2官方原文the shell receives keyboard-generated signals such as SIGINT (usually generated by ‘^C’) that users commonly intend to send to that command. This happens because the shell and the command are in the same process group as the terminal, and ‘^C’ sends SIGINT to all processes in that process group.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 3 章3官方原文the shell does not receive keyboard-generated signals, because it is not in the same process group as the terminal.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 3 章4官方原文If the command terminates due to the SIGINT, Bash concludes that the user meant to send the SIGINT to the shell as well, and acts on the SIGINThttps://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 4 章5官方原文If the command does not terminate due to SIGINT, the program handled the SIGINT itself and did not treat it as a fatal signal. In that case, Bash does not treat SIGINT as a fatal signal, either…官方在本句后举的例子是编辑器把 SIGINT 当作普通操作例如中止一条编辑命令https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 4 章6官方原文The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.要让某个作业不收到它可用 disown 把该作业从作业表里移出https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 5 章7官方原文The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. The first signal can be changed with the STOPSIGNAL instruction in the container’s Dockerfile, or the --stop-signal option to docker run and docker create.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章8官方原文If no default is configured for the container, the Daemon determines the default, and is 10 seconds for Linux containers, and 30 seconds for Windows containers.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章9官方原文If the container does not exit after the timeout elapses, it’s forcibly killed with a SIGKILL signal.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章10官方对--signal的说明Signal to send to the container对--timeout/-t的说明Seconds to wait before killing the containerhttps://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章11官方原文If you set --timeout to -1, no timeout is applied, and the daemon waits indefinitely for the container to exit.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章说明第 1–6 行取自 Bash 官方手册 3.7.6 Signals 一节第 7–11 行取自 Docker CLI 对docker container stop的参考页均由本批次于2026-09-27一手核验。本文所有命令均未实测已在正文逐处标注代码待验证本文不列任何信号编号对照表。附表 B术语速查表术语一句话解释控制层本文的观察对象你怎么把一件事停下来以及停下来这个动作发给了谁信号终端或 shell 发出去的一个通知按键不等于停止只是把通知寄出去SIGINT中断组合键产出的那个信号官方措辞是usually generated by ^CSIGTERM容器停止时默认先发给主进程的那个信号交互式 shell 对它是忽略SIGKILL宽限期用完之后才发出去的那个信号属于强制结束SIGQUIT交互式 Bash 在任何情况下都忽略的那个信号SIGHUPshell 收到后默认退出的那个信号退出前会转发给它带的所有作业前台命令当前正在终端里跑、占着输入输出的那条命令进程组一组进程的集合键盘信号发给的是终端那个进程组里的所有进程作业控制启用后 shell 会把自己移出终端那个进程组因此收不到键盘信号两条判定未启用作业控制时shell 等前台命令结束后做的分岔判断宽限期容器停止时留给主进程自己收尾的那段时间主进程容器里被指定为主要那一个的进程停止信号先发给它STOPSIGNAL镜像里用来改写第一封信叫什么名字的那条指令disown把某个作业从作业表里移出使它在 shell 退出时不被转发到信号只读动作本文给出的全部动作类型只看不改不启动、不停止、不修改代码待验证本文命令未在本机实测的标记请以官方文档为准写在最后这篇用到的资料写这篇文章时我把 Bash 官方手册讲信号的那一节和 Docker 官方讲容器停止的那一页对照着读了一遍。发现停不下来这件事官方其实拆成了三段信号发给谁、谁收到之后怎么处理、宽限期里到底在等什么。这三段散在两份文档里于是顺手整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份先把这台机器上还有哪些东西在等着你这件事想清楚再回头看你的容器有没有自己的默认值——控制这一层的问题多数是在这里定下来的。 命令跑了半天停不下来：信号与前台进程这一层
授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、一条命令停不下来先分清是哪一件事1.1 事情往往是这样开始的你敲了一条命令屏幕上开始往外滚东西或者干脆什么都不动只有光标在那儿等着。你觉得不对劲按下了中断组合键。有时候一次就回来了提示符重新出现有时候你按了三四次屏幕还是老样子。更让人迷惑的是同一条命令、同一个终端昨天按一次就回来今天怎么按都没用。还有另一种情形你直接关掉终端窗口以为事情就这样结束了。过了一会儿新开一个终端去看发现之前那个东西还在跑。这几种现象嘴上说的都是停不下来可它们落在不同的位置上。第一种是你发出的信号到底给了谁、对方有没有理它第二种是发信号的那个源头终端走了之后作业被怎么处置。本文讲的是前一层信号与前台进程。1.2 分流只需要三个问题分流不需要复杂工具三个问题就够。第一个问题按键之后命令本身有没有变化如果它停了说明信号送到了而且被当成了要处理的事如果它毫无反应那要问的就是——信号没送到它手里还是它收到了却选择不理。这两个原因的解释完全不同。第二个问题你按了几次一次就回来和按好几次才有反应看起来是两个毛病其实是同一件事的两面。原因在第三章和第四章。第三个问题终端窗口是不是被你关掉了如果是那走的根本不是按键这条路而是第五章要讲的另一条路。这三个问题各自对应一个只读动作。⚠️代码待验证ps# 只读看当前这个会话下有哪些进程dockerps# 只读看容器列表以及它们各自当前的状态两条都只做看这一件事不启动、不停止、也不改任何配置。你看到的现象更可能落在哪一层本文的哪一章按键之后命令停了提示符回来了信号送到了而且被当成要处理的事第三章、第四章按了好几次命令还在跑信号到了但接收方自己接管了它第四章关掉终端之后它居然还在跑终端退出与作业被如何处理第五章容器停不下来过几秒才停容器的停止信号与宽限期第六章1.3 本文只讲控制层先把范围说清楚。本文的观察对象是控制层你怎么把一件事停下来以及停下来这个动作到底发给了谁。有几件事本文不写不写怎么强行终止别人的进程不写进程注入这一类话题也不展开容器的资源限制与内存那一层。文中出现的每一条命令都只做看这件事。二、中断组合键发出的是哪个信号2.1 一个键一个信号按下中断组合键之后终端做的事不是把那条命令关掉而是发出一个信号。这一点是所有后续讨论的前提按键本身不等于停止按键只是把一封信寄出去。这封信叫什么名字官方手册写得很直接。Bash 官方手册在讲信号的那一节里描述这个信号来源时用的措辞是usually generated by ^C——也就是说中断组合键产出的信号就是SIGINT。那么停下来这个动作是谁做的是收到信号的那个进程自己做的。信号到了它手上它可以按默认方式对待对SIGINT来说默认就是终止自己也可以自己接管、决定不终止。所以按了键和停下来了之间从来不是等号。2.2 shell 自己对这些信号的态度还有一个容易被忽略的角色shell 本身。你在终端上敲的那个键最终是终端把信号发给了一批进程而 shell 在不在这批进程里取决于下一章要讲的进程组归属。同时shell 收到某些信号时也有自己的默认态度。官方原话是逐字引用When Bash is interactive, in the absence of any traps, it ignores SIGTERM (so that ‘kill 0’ does not kill an interactive shell), and catches and handles SIGINT (so that the wait builtin is interruptible). When Bash receives a SIGINT, it breaks out of any executing loops. In all cases, Bash ignores SIGQUIT.这段话里含三件事逐条拆开看第一交互式 shell 忽略SIGTERM你在终端里冲着这个 shell 发SIGTERM它不会因此退出官方还给这条设计配了理由——为了不让kill 0把交互式 shell 干掉。第二交互式 shell 会接住并处理SIGINT目的是让wait这个内建命令可以被中断它收到SIGINT之后会跳出正在执行的循环。第三在任何情况下Bash 都忽略SIGQUIT。官方用的是In all cases没有留例外。截至 2026-09-27官方手册这一节对交互式 shell 的口径就是上面这三句。信号名交互式 Bash 的默认态度官方依据逐字要点本文位置SIGTERM忽略it ignores SIGTERM (so that kill 0 does not kill an interactive shell)本章SIGINT接住并处理收到后跳出正在执行的循环catches and handles SIGINT (so that the wait builtin is interruptible)本章SIGQUIT在任何情况下都忽略In all cases, Bash ignores SIGQUIT.本章SIGHUP默认退出The shell exits by default upon receipt of a SIGHUP.第五章2.3 信号名从哪里来信号是一组带名字的东西kill -l这个动作的作用就是把信号名列出来。本文只把它是一个列出信号名的动作这件事放在这里不贴它列出的内容——本批一律不贴终端里的原始输出。⚠️代码待验证kill-l# 只读列出信号名不发送任何信号也不改变任何东西有一点要单独说清楚kill -l只是看名字它自己不发信号、不结束任何进程。名字和编号的对应关系请以你自己系统上的手册为准本文不列任何编号对照表讨论范围只涉及五个名字SIGINT、SIGTERM、SIGKILL、SIGQUIT、SIGHUP。三、键盘信号到底发给了谁3.1 未启用作业控制同一个进程组这是全文最硬的一条也是为什么有时按一下就回来了、有时按好几次也没用的根子。官方原话逐字引用the shell receives keyboard-generated signals such as SIGINT (usually generated by ‘^C’) that users commonly intend to send to that command. This happens because the shell and the command are in the same process group as the terminal, and ‘^C’ sends SIGINT to all processes in that process group.把这段翻成要点是三层意思第一你在终端里按下中断键时这个信号的收件人不是你以为的那一个进程而是终端那个进程组里的所有进程。第二之所以这件事会顺带打到 shell 身上是因为未启用作业控制时shell 和它正在跑的那条命令处在同一个进程组里——也就是与终端相关联的那个进程组。第三官方对这句话的用途也说得很明白用户的本意是把这个信号发给那条命令但因为两者同组shell 也跟着收到了。这解释了一个很日常的现象——你按中断键的时候那条命令停了命令行会话有时候也会跟着顿一下。3.2 启用作业控制shell 不在那个进程组里那么为什么有时候感觉又不一样了因为 shell 到底在不在那个进程组里是会变的。官方对另一种情形的表述是逐字引用the shell does not receive keyboard-generated signals, because it is not in the same process group as the terminal.启用作业控制之后shell 把自己移出了与终端关联的那个进程组于是键盘产生的信号打不到它身上。信号还是照发只是那份收件名单里没有它了。两种情形并排看就是下面这张表情形shell 在不在终端那个进程组里键盘信号发给谁shell 会不会收到未启用作业控制在该进程组里的所有进程会收到启用作业控制不在该进程组里的进程不含 shell不会收到这张表解决了本文开头那个困惑的前一半你按下的每一次信号都发出去了但到底有几方收到取决于当时谁和谁在同一个组里。3.3 为什么这件事对排障有用这一章的价值不在于记住进程组这个词而在于改掉一个默认假设你在终端里按键不是你直接对那条命令说话而是往一个组里广播了一封信谁收到、谁理它是接收方自己的选择。所以当你发现我按了它没停的时候第一条判断不是我按得不够用力而是这封信到了它手上没有以及它收到之后做了什么。后半个问题就是下一章。⚠️代码待验证ps# 只读看当前会话下有哪些进程以及它们各自的归属信息本文不给怎么改进程组归属的示范动作——那属于改环境的操作不是看。四、命令结束之后shell 的两条判断4.1 未启用作业控制时shell 还要再判一次前两章讲了未启用作业控制时shell 和命令在同一个组里所以 shell 自己也收到了那个信号。既然收到了shell 该怎么做官方说它会等前台命令先结束然后做判断判断的依据是这条命令是怎么结束的。于是就有了两条路。第一条路命令确实是因为这个信号而结束的。官方原话逐字引用If the command terminates due to the SIGINT, Bash concludes that the user meant to send the SIGINT to the shell as well, and acts on the SIGINT意思是既然命令是被SIGINT终止的Bash 就认为你本来也想让 shell 收到这个信号。走这一条路你按一次键命令停了shell 也按收到SIGINT的方式动作——所以提示符干脆地回来了。第二条路命令不是因为这个信号而结束的。官方原话逐字引用If the command does not terminate due to SIGINT, the program handled the SIGINT itself and did not treat it as a fatal signal. In that case, Bash does not treat SIGINT as a fatal signal, either…意思是如果命令没被这个信号干掉那就说明这个程序自己接管了这个信号并且不把它当成会要命的信号。这种情况下Bash 也不把它当成会要命的信号。官方在这里举了一个很具体的例子编辑器会把SIGINT当成一个普通操作来处理比如中止一条正在进行的编辑命令而不是退出程序本身。4.2 这就解释了按了没用把这两条路放在一起那个困惑就解开了。你按下中断键信号发到了整个进程组里前台那个程序收到了。接下来往哪条路走取决于这个程序自己愿不愿意停它愿意停命令结束Bash 判定你也想让 shell 停shell 跟着一起动作它自己接管了这个信号、并且不认为这个信号要命它就会继续跑Bash 也跟着不把它当回事。所以按好几次才有反应这件事多数时候不是信号没送到而是接收方每一次都选择了自己处理。你按多少次它就自己处理多少次只有当它处理到某个边界、真的退出了这个循环才结束。还要补一个前提这条判断是未启用作业控制时的逻辑。启用作业控制时shell 根本不在那个组里、收不到键盘信号也就谈不上跟着一起停。命令结束的方式Bash 的判断你看到的结果命令因该信号而结束认为你也想把这个信号发给 shell并且照做命令停shell 也跟着动作命令没因该信号结束程序自己处理了它不把这个信号当成会要命的信号命令继续跑看起来像按了没用⚠️代码待验证信号送到了 和 对方停下来了 是两件事判断顺序是 1. 这个信号发出去了吗——按键这个动作本身就发出去了。 2. 谁收到了——取决于当时谁和谁在同一个进程组里第三章。 3. 收到的人怎么处理它——它自己说了算这就是本章的两条分岔。五、关掉终端窗口之后SIGHUP 与 disown5.1 shell 收到 SIGHUP 就退出前面几章讲的是按键这条路。还有一条路是终端本身没了你关掉终端窗口或者连接断开了。官方对 shell 在这种情况下的行为写得很明确逐字引用The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.两句话两个要点。第一shell 收到SIGHUP时默认行为就是退出。第二也是最容易让人意外的一点在退出之前交互式 shell 会把这个SIGHUP再发一遍给它手上的所有作业不管这些作业是正在运行的还是已经停下的。也就是说关掉终端这件事不是只管 shell 自己它会顺手把信号转发出去。这一条正好解释了本文开头那个现象。你以为关掉窗口就等于结束了其实这条链是这样的终端没了 → shell 收到SIGHUP→ shell 决定退出 → 退出之前先把SIGHUP转发给它带着的那些作业。至于每个作业收到之后停不停仍然回到第四章那个问题——它自己怎么处理这个信号。5.2 让某个作业不收到它既然默认是转发给所有作业那自然会有一个反过来的需求我不想让某个作业收到这封信。官方给的答案是disown——把这个作业从作业表里移出它就不会被转发到了。这里要分清的是disown处理的是要不要把它算在我的作业里这件事而不是给它发一个停止信号。它本身不是一种停下来的动作它改变的是一份名单。5.3 交互式 shell 对 SIGTERM 与 SIGQUIT回到第二章那张表把两种外来信号再对一次交互式 shell忽略SIGTERM理由是为了不让kill 0把交互式 shell 干掉并且在任何情况下都忽略SIGQUIT。这两条合起来能回答一个常见的疑问“我在终端里冲着 shell 发一个终止信号它怎么不退出”——因为这是它有意为之的默认态度不是它坏了。要让它走走的是另一条路终端退出带来的SIGHUP。情形默认行为官方依据逐字要点交互式 shell 收到SIGTERM忽略it ignores SIGTERM (so that kill 0 does not kill an interactive shell)交互式 shell 收到SIGQUIT在任何情况下都忽略In all cases, Bash ignores SIGQUIT.交互式 shell 收到SIGINT接住并处理catches and handles SIGINT交互式 shell 收到SIGHUP默认退出退出前把SIGHUP转发给所有作业运行中的与已停止的The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.想让某个作业不被转发到用disown把它从作业表里移出同上下面这份资料把信号发给谁、谁理它、终端退出之后作业怎么办这三段整理成了一页和本章的对照表呼应配套资料把信号归属、两条判定、终端退出整理成一页对照表放在资料包里扫码即可获取六、容器这一侧docker stop 之后为什么要等几秒6.1 默认先 SIGTERM宽限期后才 SIGKILL前五章讲的是你在终端里跑东西。容器里的程序是另一套入口但问的是同一个问题停下来这个动作到底发给了谁、发的是什么。Docker CLI 对docker container stop的说明是逐字引用The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. The first signal can be changed with the STOPSIGNAL instruction in the container’s Dockerfile, or the --stop-signal option to docker run and docker create.拆成三层看第一先发给容器里的主进程一个SIGTERM。注意是主进程——容器里往往有好几个进程在跑先收到这封信的是被指定为主进程的那一个。第二宽限期过去之后再发SIGKILL。官方在另一句里把这件事说得更直逐字引用If the container does not exit after the timeout elapses, it’s forcibly killed with a SIGKILL signal.也就是说宽限期是给它一个自己收尾的机会这个机会用完了它还没退才走强制结束那一手。这就回答了本文开头那个问题docker stop之后为什么要等几秒——那几秒不是命令卡了而是它本来就在等等主进程自己把收尾做完。第三第一封信的名字是可以换的换的地方有两个镜像里的STOPSIGNAL或者启动时的--stop-signal选项。6.2 默认是几秒以及这个数到底从哪来关键的一句在这里逐字引用If no default is configured for the container, the Daemon determines the default, and is 10 seconds for Linux containers, and 30 seconds for Windows containers.这句话里有一个极容易被略过去的条件“如果没有为容器配置默认值”。也就是说这个数不是容器自己带来的而是在容器没有自带配置的时候由守护进程来决定。截至 2026-09-27官方这一页给出的守护进程口径是Linux 容器 10 秒Windows 容器 30 秒。为什么要强调默认值从哪来因为它直接决定排障的下一步。你看到等了十来秒才停不一定说明这条命令写死了 10 秒而可能是这个容器没有自己的配置、落到了守护进程的默认上。要确认走的是哪一条默认就得看容器本身有没有配过。6.3 信号与宽限期怎么改官方对这两个开关的说明是逐字引用--signalSignal to send to the container--timeout/-tSeconds to wait before killing the container两条合起来就是这一章的全部机制一个开关决定第一封信叫什么名字另一个开关决定等多久。宽限期这个数由超时参数给出官方在这一页写作--timeout简写-t在不同入口下它也可能写作--stop-timeout具体以你所用入口的文档为准。而等多久还有一个特殊取值逐字引用If you set --timeout to -1, no timeout is applied, and the daemon waits indefinitely for the container to exit.设成-1就是不设时限守护进程会一直等下去等到容器自己退出为止。这一条用的时候要留意它不是一个更快停下来的设置而是一个不再走强制那一手、愿意一直等下去的设置。你观察到的现象对应的机制官方依据逐字要点docker stop之后等了几秒才停宽限期到了才走强制结束after a grace period, SIGKILL等待的时间大约是十来秒Linux 容器容器没配默认值由守护进程决定If no default is configured for the container, the Daemon determines the default想换第一封信的名字镜像的STOPSIGNAL或--stop-signalcan be changed with the STOPSIGNAL instruction ... or the --stop-signal option想改等待时长宽限期参数--timeout/-tSeconds to wait before killing the container想不设时限、一直等把超时设为-1no timeout is applied, and the daemon waits indefinitely6.4 只读地看一眼容器现在是什么状态⚠️代码待验证dockerps# 只读看容器列表与当前状态dockerinspect容器名# 只读看这个容器自身的配置里有没有覆盖默认值docker inspect在这里的用处就是回答 6.2 那个问题这个容器的默认值是不是没配。没配时间就来自守护进程配过就是配置里写的那一条。本文不给停止容器的示范动作——这里只讲停下来这个动作的语义。七、把这一层变成动作7.1 三个只读动作第一步先看东西还在不在。⚠️代码待验证ps# 只读看当前会话下还有哪些进程dockerps# 只读看容器列表和它们当前的状态这一步回答的是分流里的第一个问题。重点不是看它跑得好不好而是先确认它在不在。第二步看它有没有自己的配置。⚠️代码待验证dockerinspect容器名# 只读看容器自身的信号与超时相关配置有没有被改过dockerversion# 只读确认你在跟哪一个客户端与守护进程打交道第二步回答的是第六章那个默认值从哪来的问题没配过才是守护进程的默认。而docker version用来确认你面对的是哪一个守护进程——同一台机器上装了两个环境时这一步能省掉很多绕路。7.2 现象到动作的对照表把前面几章的判断收成一张表出问题时按行对号现象更可能落在哪一层先做哪个只读动作按中断键命令停了信号送到了而且被当成要处理的事看它是否已经不在进程列表里按了好几次命令还在跑接收方自己接管了这个信号先确认它是不是本来就这么设计别再重复按键关掉终端之后它还在终端退出与作业被如何处理看还有哪些进程活着再考虑disown这类名单调整docker stop之后等了几秒容器的宽限期看这个容器有没有属于自己的默认值配置对 shell 发终止信号它不理交互式 shell 有意忽略SIGTERM不用重试这就是它的默认行为这张表只需要记住一句先判断信送到了没有和对方理不理再决定要不要做别的动作。7.3 一页自检表与三条可带走的动作出问题的时候先把下面这张自检表过一遍检查项为什么查它在哪一层我按的是哪一类键不同的键产出不同的信号名信号来源当时 shell 在不在同一个进程组里决定 shell 会不会也收到这封信进程组归属命令是被告知结束的还是自己收尾的决定 shell 下一步跟不跟着停两条判定终端是不是没了SIGHUP走的是另一条路终端退出这个容器有没有配过默认值没配过这个数就来自守护进程容器侧我想做的动作是不是强行结束别人不在本文范围也不该做边界三条可以带走的动作先分清是没送到还是不理会按键这个动作每次都会把信号发出去差别在接收方。容器侧先看配置有没有被覆盖没被覆盖走的才是守护进程的默认。不要靠重复按键来解决问题重复按解决不了接收方自己的选择。本文的使用限制所有命令均为待验证本文写作环境没有可用的 docker 环境文中每条命令都没有实际运行过参数写法与默认行为请以各自官方文档为准。本文不写任何命令的输出文本kill -l只作为列出信号名的动作出现本文不列它列出的内容也不列任何信号编号对照表。本文不给可照抄的停止示范不写怎么强制结束进程不写进程组归属怎么改。其它层不在本文范围容器的资源限制与内存那一层另有专文本文只讲信号与时序。把这一层的判断顺序整理成一页放在资料里和本章的自检表呼应配套资料把分流、看配置、别重按三步和上面这张自检表合成一页放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表#事实照口径一手出处 URL核验日期本文位置1官方原文When Bash is interactive, in the absence of any traps, it ignores SIGTERM (so that ‘kill 0’ does not kill an interactive shell), and catches and handles SIGINT (so that the wait builtin is interruptible). When Bash receives a SIGINT, it breaks out of any executing loops. In all cases, Bash ignores SIGQUIT.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 2、5 章2官方原文the shell receives keyboard-generated signals such as SIGINT (usually generated by ‘^C’) that users commonly intend to send to that command. This happens because the shell and the command are in the same process group as the terminal, and ‘^C’ sends SIGINT to all processes in that process group.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 3 章3官方原文the shell does not receive keyboard-generated signals, because it is not in the same process group as the terminal.https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 3 章4官方原文If the command terminates due to the SIGINT, Bash concludes that the user meant to send the SIGINT to the shell as well, and acts on the SIGINThttps://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 4 章5官方原文If the command does not terminate due to SIGINT, the program handled the SIGINT itself and did not treat it as a fatal signal. In that case, Bash does not treat SIGINT as a fatal signal, either…官方在本句后举的例子是编辑器把 SIGINT 当作普通操作例如中止一条编辑命令https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 4 章6官方原文The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.要让某个作业不收到它可用 disown 把该作业从作业表里移出https://www.gnu.org/software/bash/manual/html_node/Signals.html2026-09-27第 5 章7官方原文The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. The first signal can be changed with the STOPSIGNAL instruction in the container’s Dockerfile, or the --stop-signal option to docker run and docker create.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章8官方原文If no default is configured for the container, the Daemon determines the default, and is 10 seconds for Linux containers, and 30 seconds for Windows containers.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章9官方原文If the container does not exit after the timeout elapses, it’s forcibly killed with a SIGKILL signal.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章10官方对--signal的说明Signal to send to the container对--timeout/-t的说明Seconds to wait before killing the containerhttps://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章11官方原文If you set --timeout to -1, no timeout is applied, and the daemon waits indefinitely for the container to exit.https://docs.docker.com/reference/cli/docker/container/stop/2026-09-27第 6 章说明第 1–6 行取自 Bash 官方手册 3.7.6 Signals 一节第 7–11 行取自 Docker CLI 对docker container stop的参考页均由本批次于2026-09-27一手核验。本文所有命令均未实测已在正文逐处标注代码待验证本文不列任何信号编号对照表。附表 B术语速查表术语一句话解释控制层本文的观察对象你怎么把一件事停下来以及停下来这个动作发给了谁信号终端或 shell 发出去的一个通知按键不等于停止只是把通知寄出去SIGINT中断组合键产出的那个信号官方措辞是usually generated by ^CSIGTERM容器停止时默认先发给主进程的那个信号交互式 shell 对它是忽略SIGKILL宽限期用完之后才发出去的那个信号属于强制结束SIGQUIT交互式 Bash 在任何情况下都忽略的那个信号SIGHUPshell 收到后默认退出的那个信号退出前会转发给它带的所有作业前台命令当前正在终端里跑、占着输入输出的那条命令进程组一组进程的集合键盘信号发给的是终端那个进程组里的所有进程作业控制启用后 shell 会把自己移出终端那个进程组因此收不到键盘信号两条判定未启用作业控制时shell 等前台命令结束后做的分岔判断宽限期容器停止时留给主进程自己收尾的那段时间主进程容器里被指定为主要那一个的进程停止信号先发给它STOPSIGNAL镜像里用来改写第一封信叫什么名字的那条指令disown把某个作业从作业表里移出使它在 shell 退出时不被转发到信号只读动作本文给出的全部动作类型只看不改不启动、不停止、不修改代码待验证本文命令未在本机实测的标记请以官方文档为准写在最后这篇用到的资料写这篇文章时我把 Bash 官方手册讲信号的那一节和 Docker 官方讲容器停止的那一页对照着读了一遍。发现停不下来这件事官方其实拆成了三段信号发给谁、谁收到之后怎么处理、宽限期里到底在等什么。这三段散在两份文档里于是顺手整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份先把这台机器上还有哪些东西在等着你这件事想清楚再回头看你的容器有没有自己的默认值——控制这一层的问题多数是在这里定下来的。