隐私政策

本站收集的信息

本站使用 Blogger 托管。访问本站时，托管平台可能会记录常规的访问日志，例如访问时间、浏览器类型和粗略的地理位置，用于维持网站正常运行。本站作者本人不主动收集读者的姓名、电话、身份证号等个人信息。

Cookie 与广告

本站计划展示 Google AdSense 广告。Google 及其合作伙伴可能会使用 Cookie，根据你过往访问本站和其他网站的情况展示广告。你可以在 Google 广告设置里管理个性化广告，也可以在浏览器设置里清除或禁用 Cookie。

第三方链接

文章中出现的第三方网站链接，跳转后适用对方网站的隐私政策，与本站无关。

联系方式

如果你对本政策有疑问，可以通过联系页面上的方式联系我。本政策如有修改，会在本页更新，不另行通知。

最后更新：2026 年 10 月

评论

发表评论

此博客中的热门博文

甲骨文免费额度怎么算：2 核 12G 为什么正好跑满一个月

先说结论 甲骨文云免费套餐里，ARM 实例（A1.Flex）的免费额度是 全账号共用的一池子小时数 ，不是按台算的。一个月按 730 小时算， 2 核 12G 常开一个月，正好吃掉约 1460 OCPU 小时 + 8760 GB 小时，刚好卡在免费额度里面 。这就是为什么 2 核 12G 是"免费甜点"，往上调任何一点都会开始计费。 免费额度其实是两本账 很多人第一次算错，是因为把两种免费额度混成了一本。其实是分开的： 第一本账：A1.Flex，按小时池算。 全账号每月共用 1500 OCPU 小时 + 9000 GB 内存小时 （2026 年 6 月之后减半后的口径，之前是两倍）。一台机器开多久、什么规格，都从这个池子里扣。 第二本账：E2.1.Micro，按台数算。 全账号最多 2 台，和 A1 的小时池互不相干。E2 的机器不吃 A1 的池子，A1 的机器也不占 E2 的名额。 算账的时候先分清你开的是哪种，A1 只看小时池。 算一遍就明白了 一个月按 730 小时算（365 天 ÷ 12 个月 × 24 小时，实际月份有 28–31 天，数字会略有浮动）： 2 核 12G 常开 ：2 × 730 = 1460 OCPU 小时 ，12 × 730 = 8760 GB 小时 。对照 1500 / 9000 的池子，两项都刚好在里面，只剩一点零头。 4 核 24G 常开 ：4 × 730 = 2920 OCPU 小时，24 × 730 = 17520 GB 小时。两项全部超标，超出的部分按量计费。 哪怕只加到 3 核 18G ：3 × 730 = 2190 OCPU 小时，18 × 730 = 13140 GB 小时。还是超。 所以纪律很简单： A1 的规格只许保持 2 核 12G，往上调任何一点都会溢出 。再开第二台 A1 也一样，约等于每月多花几十美元量级的费用。 三个容易踩的坑 第一，免费不等于不会扣费。 升级成按量付费（PAYG）之后，闲置回收那套就不适用了：超免费额度的部分是真扣费，不是关机回收。所以规格纪律比以前更重要。 第二，公网 IPv4 不收费。 这一点我专门核对过甲骨文官方的虚拟网络定价页：公网 IPv4 地址本身没有按小时收费，别被网上搬错的价目表吓到。 第三，主区域定死不能改。 注册时选的主区域（比如大阪）是永...
阅读全文

FinalShell 打开远程文件报“下载失败”：先断开重连，别先改权限

先说结论 用 FinalShell 双击打开远程服务器上的文件，弹出“下载失败”，第一反应应该是 先断开连接、重新连一次，再试一次 。很多时候这一步就好了，根本不用动服务器上的任何东西。 我踩过一次：当时先怀疑文件权限，查了一圈服务器，文件可读、磁盘有空间、SSH 的 SFTP 配置也正常，最后断开重连，立刻就能打开了。问题不在文件，也不在服务器，在 FinalShell 那个挂了很久的会话本身。 症状长这样，你就按这篇来 典型的表现是“一半正常、一半不正常”，很容易误导人： 左侧文件列表还能正常显示，服务器明明连着； 双击某个文件想打开编辑，却报“下载失败”； 换个文件试，还是打不开。 看到这种“列表在、下载不通”的组合，先别急着下结论。文件列表走的是会话里还能用的部分，下载走的是已经发僵的那条 SFTP 通道，两边状态不一样，才会出现这种半正常现象。 正确的排查顺序 第一步：断开，重连，再打开。 在 FinalShell 里把当前连接断开，重新连上服务器，再双击同一个文件。如果能打开了，事情就结束了，不用再往下查。 第二步：还打不开，再看服务器侧。 按这个顺序过一遍，别跳步： 文件是不是真的存在、当前登录账号能不能读它； 服务器磁盘是不是满了； SSH 服务和 SFTP 相关配置有没有被改坏。 第三步：最后才考虑改权限。 只有确认了“确实是权限不够”再改。权限改错了比不改更麻烦：改松了是安全口子，改错了属主还可能把原来能跑的服务弄停。把“改权限”放在最后，本身就是在省事。 为什么重连会好 FinalShell 的会话挂久了，里面的 SFTP 通道会发僵：连接看着还在，实际上下载数据的那条路已经不通了。断开重连就是换一条新的通道，文件、服务器什么都没变，路通了自然就好了。 所以这条经验可以记成一句话： FinalShell 报下载失败，先重连，再查服务器，最后才动权限。 顺序反过来，前面查的那一圈全是白费功夫。
阅读全文

Windows 文件怎么备份到云服务器：SFTP 手动备份

  先说结论 Windows 文件备份到云服务器，不用在服务器上装任何软件。用 FinalShell 的 SFTP 功能，手动把文件上传到服务器上的备份目录就行。服务器零改动，备份这件事只发生在你 Windows 这一侧。 为什么选手动 SFTP 备份方案一开始有好几个选项：装同步软件、搭网盘服务、写自动脚本。最后定的是最简单的那一个，理由就一条： 服务器上什么都不用装 。 云服务器上每多装一个服务，就多一个要维护、要更新、要防出问题的东西。只为备份文件，不值得。SFTP 是 SSH 自带的文件传输能力，服务器装好 SSH 就能用，Windows 这边用 FinalShell 连上去就能传，不用双方再装任何东西。 四步传上去 第一步：FinalShell 连上服务器。 正常登录就行，跟平时连服务器一样。 第二步：打开 SFTP 面板。 FinalShell 连上之后，界面下方（或者侧边）有 SFTP 的文件浏览区，左边是你 Windows 本地的文件，右边是服务器上的目录。 第三步：右边进备份目录。 在服务器那一侧，进到事先建好的备份目录，比如 /Backup_Win 。注意两点： Linux 路径区分大小写， /Backup_Win 和 /backup_win 是两个不同的地方，字母大小写要一模一样； 这个目录在根目录 / 下面，不是 /root 下面，别进错了。 第四步：左边选文件，上传。 在本地一侧选中要备份的文件或文件夹，拖到右边，或者点上传按钮。传完先别急着关，看一眼右边的目录，文件是不是都在。 备份前先想好：备什么 别一上来就把整个 C 盘往上搬。先定一个范围，比如： 文档、表格、自己写的稿子； 照片、重要的聊天记录备份； 浏览器导出的书签、软件的配置备份。 范围定好了，每次备份就是同一批东西，传得快，也容易发现有没有漏。 传完验证一下 手动备份最容易漏的一步就是"传完不检查"。养成习惯，传完做两件事： 对一下数量和大小：本地选了多少文件、右边是不是同样的数量； 抽查一个：随便在服务器侧双击打开一个刚传上去的文件，能打开就是真传上去了。 如果上传中途报失败，先别怀疑文件和服务器，按第二篇的经验： 先断开重连再试 ，FinalShell 会话挂久了 SFTP 通道发僵也会导致上传失败。 手动备份的短板，和升级路线 手动备份只有一...
阅读全文