跳转至

快速问答/重复问答内容手册

How To Ask

根据原文协议 CC-BY-NC-SA 4.0 摘抄部分内容以供回答时使用：
原文&原作：https://lug.ustc.edu.cn/wiki/doc/howtoask/

请先尝试自己解决问题：有的时候解决方法比想像的要简单得多（并且自己解决也比问别人快得多）。
很多时候遇到的问题会伴随着错误信息，至少分一点点耐心去读一下错误信息可能对解决问题很有帮助。如果有能力的话，尝试从日志等地方收集相关的信息也很可能会有帮助。

避免 X-Y 型问题

X-Y 型问题指代这样一种情况：你遇到了 X 问题，你相信用 Y 方法可以解决 X 问题，但是不知道怎么使用，因此向别人提问如何使用 Y 的问题，而不告诉其他人 X 问题的内容。如果用 Y 方法解决 X 问题的思路是错误的，那么这样的提问就是浪费时间。

避免「在吗」/「有人吗」

在群聊的场景下，直接问问题比问「有人吗」是更好的选择——毕竟其他人有充分的理由不理你。例如：
A (8:00): 在吗？
B (13:00): 怎么了？
A (15:00): 我遇到了 XXXXXXX 错误，然后 YYYY 命令跑不了，怎么办？
B (16:00): 你应该 ZZZZZZZ

对比之下，直接提问：
A (8:00): Hi，我遇到了 XXXXXXX 错误，然后 YYYY 命令跑不了，怎么办？
B (13:00): 这样，你应该 ZZZZZZZ
节省了大量无效交流时间。

避免「有没有人懂」

例如：有没有人懂 C++？有个问题想问问
原因如下：
C++ 是非常复杂的，没有多少人真的懂/精通 C++。对很多别的领域也是类似的。
就算真的有人懂，懂的人很可能也不想在群里（通过回答这样的问题）夸耀自己很懂。而不太懂的人就更没有兴趣看你的问题了。
很多时候对应的问题即使是不精通相关领域的人也可以回答，对应的问题可能是某种常识。

没有人回答问题 ≠ 被无视，在群聊中，如果认真提问却没有人回答，更有可能发生的事情是：看到问题的人完全不知道如何解决，仅此而已。同时也需要注意，群聊中（或者论坛中）的其他与你素不相识的人也没有必须回答问题的义务。

How To Ask Questions The Smart Way

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
https://lug.ustc.edu.cn/wiki/doc/smart-questions/
摘抄部分内容以减少攻击性和适配。注：可能违反原文分发协议，但这没办法

准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。

别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。

别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。

有一个古老而神圣的传统：如果你收到RTFM（Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。

RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）

通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为

你需要的信息非常容易获得；
你自己去搜索这些信息比灌给你，能让你学到更多。

如何有效地报告 Bug （节选）

“精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。”
“只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来。”
Copyright © Simon Tatham 1999
https://www.chiark.greenend.org.uk/~sgtatham/bugs-cn.html
licensed under OPL v1

避免低质量提问

提问时，请尽量避免以下几类问题：

  • 用主观猜测替代事实
  • 用二手信息替代原始信息
  • 在信息不足的情况下要求他人直接定位问题
  • 没有认真理解或验证回答者给出的方案

如果你希望别人能够有效帮助你，请准备好足够的信息，让其他人可以看懂你的问题、复现你的操作、判断你的结论是否成立。

L.001 不要把你的猜测当成问题本身

错误示例：

直接截图日志后询问：“为什么没有 IP？”

为什么：

因为这个问题通常已经夹带了提问者自己的假设，例如：“这个软件只能使用 IP 连接”。
但事实未必如此——如果软件支持域名连接，那么直接使用域名可能才是更合理的方法。

也就是说，原本的问题可能是：
“这一步应该填写什么才能连接？”
但提问者把它改写成了：
“日志里为什么没有 IP？”

这样的提问会把回答者带偏到你的假设里，而不是回到真正需要解决的问题上。

更好的提问方式：

  1. 如果你不确定软件是否支持域名
  2. 附上软件界面截图
  3. 附上相关日志或报错截图

  4. 直接提问：“这一步我应该填什么才能连接/联机？”

  5. 如果你已经确认软件不支持域名

  6. 提供明确证据，例如说明文档、帮助页面、设置界面截图
  7. 再提问：“如果只能使用 IP 连接，应当怎么做？”

注意事项：

  • 如果你无法提供“软件不支持域名”的依据，那么说明这只是你的猜测。
  • 这时你应当先自行测试，或按“不确认是否支持”的方式提问。
  • 不要把未经验证的前提强行塞给回答者。

L.002 不要在没有认真验证的情况下否决别人的方案

错误示例：

回答者提出一个解决方案后，提问者没有认真理解，也没有实际验证，就直接回复：
“没用”“试过了”“不行”

为什么：

这会让交流失去继续排查的基础。
除非你有非常充分的理由判断对方是在故意捣乱，否则当别人提出一个方案时，你至少应当：

  • 仔细阅读
  • 判断可行性
  • 尽量按对方描述重新做一遍
  • 把实际结果反馈出来

很多“这方法不行”的回复，本质上并不是方案本身无效，而是：

  • 操作步骤理解错了
  • 执行环境不一致
  • 中途漏了步骤
  • 还有其他配置问题没有暴露出来

更好的做法：

当你认为某个方案不可行时，请尽量提供工作量证明（Proof of Work），例如：

  • 当前配置页面截图
  • 你执行了哪个步骤的截图
  • 点击确认或执行后出现的报错截图
  • 对应日志或控制台输出

为什么要这么做：

这至少说明两件事：

  1. 你认真尝试过别人的建议，而不是随口否定；
  2. 这些截图和输出可能会暴露出其他问题，例如：
  3. 开了不该开的选项
  4. 配置填错位置
  5. 权限问题
  6. 第三方组件异常
  7. 环境与对方预期不同

分支情况：如果你看不懂对方提出的方案怎么办？

  • 直接问你不明白的步骤
  • 让对方换一种表达方式
  • 询问是否有另一种实现思路

注意事项：

  • 不要在没理解方案的情况下乱操作。
  • 误操作往往只会让问题更复杂，甚至引入新的故障。
  • “看不懂”不是问题；“没看懂还硬做”才是问题。

L.003 报错时请提供原始输出，不要自行翻译或转述

错误示例：

  • 把英文报错机翻成中文后贴出来
  • 只用自己的话概括错误，而不提供原文
  • 只说“提示某某模块有问题”，但不给完整报错内容

为什么：

因为翻译、转述和总结都会丢失信息。
而排查问题时，最有价值的往往恰恰是那些最容易在转述中消失的内容，例如：

  • 专有名词
  • 错误码
  • 文件名
  • 路径
  • 行号
  • 调用栈 / traceback
  • 参数名
  • 命令原文
  • 前后文日志

一旦这些信息被翻译错、记错或省略，回答者就只能反向猜测原始错误，这会显著降低排查效率。

更好的做法：

  1. 优先提供原始输出
  2. 能复制文本就尽量复制文本

  3. 不要只发截图，尤其不要只截取其中一小块

  4. 如果你担心别人看不懂原文

  5. 可以在原始输出后面补充你的理解或翻译

  6. 但翻译只能作为补充，不能替代原文

  7. 如果报错内容太长

  8. 可以截取关键片段
  9. 但应明确说明哪里被省略了

  10. 最好同时保留完整日志，便于后续补充

  11. 如果你必须使用截图

  12. 尽量截全
  13. 保留时间、命令、上下文和完整错误信息
  14. 不要只截一句“报错了”

推荐写法示例：

执行命令后出现如下原始输出：
[粘贴原文]

我的理解是这里可能和权限/路径有关，但我不确定。

注意事项：

  • 原始输出是排查问题的一手信息。
  • 你的解释可以有，但不能代替原文。
  • 先给事实，再谈理解；不要反过来。

L.004 不要把你和文字 AI 的对话截图当作提问内容

错误示例：

  • 直接发一张你和 AI 的聊天截图，然后问：“这怎么办？”
  • 贴出 AI 给你的整段方案，但不提供你自己的原始问题
  • 让别人阅读 AI 的二手总结，反推你的实际环境和问题

为什么：

因为 AI 对话通常是二手信息，而不是问题本身。
当你把提问内容交给 AI 处理一遍后，AI 往往会：

  • 按它自己的理解改写你的问题
  • 基于某些假设补全上下文
  • 省略它认为“不重要”的细节
  • 输出一个已经被加工过的解决方案

这会导致真人回答者无法确认以下关键信息：

  • 你最初到底问了什么
  • 你的实际环境是什么
  • AI 的回答基于哪些前提
  • 你到底执行了哪些步骤
  • 哪一步出了问题

此外，聊天截图还有额外问题：

  • 内容不易复制
  • 不易检索
  • 不方便逐句分析
  • 可能缺少前文和上下文
  • 很容易把注意力从“你的问题”转移到“AI 的回答”上

更好的做法：

  1. 直接提供你原本想问的问题

  2. 不要让别人从 AI 对话里猜你的诉求

  3. 补充真实的一手信息

  4. 你的操作步骤
  5. 软件/系统版本
  6. 报错原文
  7. 日志
  8. 配置

  9. 截图

  10. 如果你已经参考过 AI

  11. 可以直接说明：
    “我已经尝试过 AI 提出的以下方案，但没有解决问题。”

  12. 然后列出你实际尝试过的内容和结果

  13. 如果 AI 给过有价值的命令或步骤

  14. 可以把相关内容整理后贴出来
  15. 但不要只丢一张聊天截图让别人自己读

推荐写法示例：

我原本的问题是：……
我目前的环境是：……
我已经尝试过以下方案（包括 AI 提议的）：……
实际结果如下：……
相关报错/日志如下：……

注意事项：

  • AI 可以作为辅助工具，但不能替代你自己描述问题。
  • 如果你希望获得真人帮助，请尽量提供原始问题 + 原始输出 + 原始环境信息。
  • 不要把“AI 怎么说”当成“问题本身”。

高质量提问并不要求你什么都懂。
你可以不懂原理，不会分析，甚至不知道问题该怎么描述——这些都没关系。

但至少请做到以下几点：

  • 不要把猜测当事实
  • 不要把转述当原文
  • 不要把二手信息当一手材料
  • 不要在没理解、没验证的情况下直接否定回答
  • 给出足够的上下文，让别人能够真正开始排查

提问不是把问题丢出去，而是把能帮助别人理解问题的信息整理出来。
如果你愿意多提供一点一手信息，别人通常就能少花很多时间猜。

问答存档库

快速索引/搜索页：RefenceSearch.html

N.001

索引：隧道创建、网络高峰期、节点消失
last update: 2025/12/12

Pursuit.: 12-10 15:31:45
大佬们，我这几天在跟朋友一起玩我的世界，但是每天晚上开映射的时候只有几个内地隧道，这是怎么回事呀

Java8ver64: 12-10 16:35:55
你说的 “隧道” 应该指的是节点
你建好觉得好用的隧道不要删掉，不要随便看不知道哪的教程然后每天都新建隧道，隧道是重复使用的，而不是一次性物品

TIPS：在负载高的时候樱花会暂停新建隧道，但不影响建好的隧道。

N.002

索引：流量消耗、Minecraft
last update: 2025/12/10

渲染距离、模拟距离、玩家数、在线时间、模组（数量、用法、地形、代码质量）、插件、服务器玩法（机器、地形、预载）、玩家玩法（刷图、机器、背包）等都会影响游戏需要传输的数据大小

你可以尝试使用 https://www.curseforge.com/minecraft/mc-mods/connectivity
进行排查，命令如下:
/connectivity packetsAllPlayers
列出网络使用情况最高的玩家
/connectivity packetsSummary
按包类型列出服务器上数量、速率占用最高的包
/connectivity packetsPlayer 【玩家名】
按包类型列出该玩家数量、速率占用最高的包

但很可能得到的结果是一个大类(例如玩家NBT数据)或者重要玩法模组，这种近乎无解 只能建议换包玩()

N.003

索引：安全建议、通用
last update: 2025/12/10

如果你使用映射软件，应当考虑到随时有不知道哪来的人正在高强度扫描节点的端口
任何映射到公网的端口都应当视为不安全 在无鉴权的情况下暴露可操作的端口(例如smb/rdp/ssh/内部服务器专用端口/网络操作界面)是非常危险的
只是映射游戏也要考虑备份存档，群内出过端口被扫描然后被熊的事件。

N.004

索引：Minecraft、日志、DEBUG
last update: 2025/12/10

游戏日志:
无版本隔离：.minecraft\logs\latest.log
开版本隔离：.minecraft\versions\版本名\logs\latest.log

上传文件到群文件。

如何在不能发送文件的群中发送日志: 打开文件，确认不是乱码后全选复制

把内容黏贴到 https://paste.fastmirror.net/
点送出，把给的链接发群里

N.005

索引：Minecraft、服务器列表、服务器信息、红叉
last update: 2025/12/12

我想不出来: 12-10 21:44:19
这是怎么回事呀（注：指服务器列表旁的红x）

Java8ver64: 12-10 21:44:54
点进去看报错 这个x没有用

Java8ver64: 12-10 21:45:20
如果你能进服务器但是觉得这个x不顺眼可以装这个模组 https://www.mcmod.cn/class/6048.html

我想不出来: 12-10 21:45:29
好的好的

我想不出来: 12-10 21:45:59
我和朋友用的是同一个安装包

Java8ver64: 12-10 21:46:01
fml自己通过ping判断频道的方法有问题

Java8ver64: 12-10 21:46:15
所以你要进去看报错 没报错就说明是它这个x显示错了

Java8ver64: 12-10 21:46:19
有报错看报错再说（注：指先尝试进入服务器，如果遇到问题，请截图错误界面发到群里）

Java8ver64: 12-10 21:46:23
这个x没有任何有用信息

N.006

索引：Minecraft、无法加入、refused、reset
last update: 2025/12/12

reset

如果您在尝试加入游戏的时候遇到以上报错，请按顺序排查：

  1. sakura 的日志中是否有错误？如有，请先按文档地址排查相关问题

    例如：请检查本地服务是否可访问

  2. 无法访问的用户是否可访问节点域名？

    部分校园网和公司网络会阻断对隧道的访问，可以尝试更换网络（例如断开手机 WLAN 后使用流量+热点）后再试

  3. 是否是房主/服务器端主动拒绝了连接？

    请检查游戏日志。如果不会或者没有相关知识，请参考 #N.004 后在相关群内询问。

N.007

索引：Windows、通用、杀毒、拦截
last update: 2025/12/14

如果你是被介绍来看这个页面的，那么你大概率是把 PC 或网络环境中的“防火墙”与 Windows 里的其他安全组件混在了一起，或者还不太清楚它们各自负责什么。

下面会用简要、通俗的方式介绍 Windows 中几个常见的安全相关组件，方便区分它们的作用。
除 UCPD 驱动外，其余条目的介绍均参考微软官方说明。1

组件 系列 通俗说明
Defender 防病毒（Antivirus） Microsoft Defender 负责查杀病毒、木马、勒索软件等恶意程序，也会在程序运行、下载或解压时进行实时检查。
Defender 防火墙（Firewall） Microsoft Defender 负责管理网络通信，决定某些程序或端口的联网请求是否允许通过。
Defender 基于信誉的保护（SmartScreen） Microsoft Defender 主要用于拦截可疑网站、恶意下载内容，以及信誉较差或来源不明的程序。
智能应用控制（Smart App Control） 安全中心 用于阻止不受信任或高风险程序运行，仅在部分全新安装的 Windows 11 设备上可用。
用户帐户控制（User Account Control, UAC） 安全中心 当某项操作需要更高权限时弹出确认，以防程序在未经允许的情况下修改系统。
攻击防护（Exploit Protection） 安全中心 用于缓解漏洞利用类攻击，防止某些程序通过系统或应用漏洞执行恶意行为。
用户选择保护驱动程序（UserChoice Protection Driver, UCPD） 未知 用于保护部分用户关联设置，防止程序绕过正常流程，直接修改某些默认应用和相关注册表项。

根据群友反馈，在个别情况下，微软的部分安全机制可能会影响 frpc 的运行；目前较常见的相关项主要是 Defender Antivirus、SmartScreen 和 Smart App Control。
相比之下，Windows Defender 防火墙本身并没有“默认就拦截 frpc”的普遍先例；通常只有在手动配置规则、网络环境特殊，或存在其他联动策略时，才可能对其通信造成影响。

TIPS：frp 本身就是为了暴露防火墙内的端口2 而开发的

N.008

索引：

N.009

索引：

注释

  1. https://learn.microsoft.com/ , https://kolbi.cz/blog/2025/07/15/ucpd-sys-userchoice-protection-driver-part-2/ ↩

  2. https://github.com/fatedier/frp , About: "A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet. " ↩