可惜那没有奏效，在重新构建 HTML 后 URL 仍未更改，并且仍然显示\n\u003e 哎呀！该页面不存在或已设为私密。\n\n\n还有其他想法或建议吗？
UX 工作重建是否有效？
点击“重建 HTML”按钮无效。链接未更改，仍然导向错误页面。
恢复后我注意到第二个问题。我查看了错误日志，发现了这个。链接与我重建的帖子中的链接不同：
Failed to process hijacked response correctly : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
奇怪的是，当我在浏览器中输入上述 URL 时，它实际上可以显示图标。
这是回溯
消息（报告了 5 条）
Failed to process hijacked response correctly : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
回溯
/var/www/discourse/app/controllers/static_controller.rb:160:in
read' /var/www/discourse/app/controllers/static_controller.rb:160:inblock (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:inblock in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:inblock in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:insynchronize' /var/www/discourse/lib/distributed_mutex.rb:29:insynchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:insynchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:inmemoize’
/var/www/discourse/app/controllers/static_controller.rb:138:inblock in favicon' /var/www/discourse/lib/hijack.rb:56:ininstance_eval’
那么您就不需要弄清楚如何从命令行进行重建了。
我不确定，但听起来它将该地址视为文件名而不是存储桶，不过我需要查看源代码才能确定。
关于如何修复 /short-url 损坏链接的任何其他想法/看法？
我的 Oracle Cloud 服务器也发生了同样的情况。内核恐慌了，我也恐慌了。我以为我完蛋了。但在通过云控制台进行了大约六到八次重启后，其中一些是“拔掉插头”式重启，并且在等待了大约半小时后，服务器终于启动了足够长的时间让我编辑 grub.cfg 并恢复到之前的内核。
我因此得以保住我的实例。一天后，又有一个新的内核更新可用，那时我更加确信我的内核问题理论是正确的。然后我找到了错误描述来证实它。是的，相当糟糕。
我设计了一个我称之为“愚蠢的 Grub 技巧”的方法，我会找时间匿名发布，这样以后就可以避免这种灾难了。
祝你恢复顺利，@RBoy。我必须说，这个帖子让我想起了上周（是星期三吧？）我自己的那次差点灾难，让我胃里一阵翻腾。
顺便说一句，你说你重新获得了对旧服务器的访问权限。如果你仍然拥有它，或者能够再次访问——对我来说，这需要一些强制重启和一些等待——那么，进去再更新一次，因为有一个新的内核没有这个错误。或者恢复到之前的内核。