国内ISP与国际ISP的互联详情 中国香港(HK)常见运营商：CMI、CUG、NTT、PCCW、Telia、Telstra、CHT、HKBN、HKT、WTT、HGC、GTT、TaTa、HE、Cogentco、SingTel常见数据中心：HKIX、EIEHKG（Equinix Internet Exchange HongKong）常见下游：Cloudflare、Amazon、Azure、Google、CDN77、Cera Network对于很多南方地区的用户来说，对于需要访问一些全球类的网站，离得最近的CDN网络都是在香港（延时最低）。香港机房一直都是很多面向亚太地区服务器托管商的兵家必争之地，所以也涌现出了大量的IDC商家，可惜鱼目混杂，能做到价格便宜且到国内直连的却少之又少，直连高昂的宽带单价也劝退了大部分商家。CMI – 移动自己的国际骨干网由于CMI自己也在卖香港资源，所以有些下游会选择直接购买CMI的Transit，来获得高Qos的CMI体验，这样国内用户到这些下游提供商就可以全部走移动的骨干网，来获得高性价比且高质量的访问体验。境内连接质量：非常高，只要对方下游接入了足够的CMI Transit宽带，峰值宽带基本是移动保证的。无论是电信、联通还是移动（当然移动用户访问过去，优先级是最高的）。虽然高性价比，但是毕竟是香港地区，流量单价依旧远超美欧Transit的单价。CUG – 联通自己的国际骨干网同移动的CMI，联通也卖香港资源（自治系统编号AS10099），很多下游也选择接入了CUG的资源，这对于联通用户来说，等于获得了很好的质量保证。境内连接质量：非常高，只要对方下游接入了足够的CUG Transit宽带，峰值宽带基本是联通保证的。无论是电信、联通还是移动（当然联通用户访问过去，优先级是最高的）。NTT（香港）可直连的国内骨干网：AS4809、AS58453在香港地区，只有电信CN2、移动可以直连，其中电信CN2买了NTT Transit 。其余电信163和联通169都会绕路日本和美国。连接质量：需要注意的是，CN2很多时候不是万能的，特别是香港地区。CN2到香港NTT不可靠，有时候会爆炸，延时会呈现剧烈的抖动，如果需要追求高稳定性，不推荐CN2用户使用接入香港NTT的网络。移动如果不买他们的商业高Qos宽带，在高峰时期直连NTT会被Qos，丢包和延时都会显著增加，速度一般无法超过10Mbps。对于高Qos的移动用户也并不乐观，高峰时期，因为上海和广州地区汇聚层拥堵显著，所以最高速率往往也无法超过200Mbps特殊CM2精品网大客户除外，因为你加钱买了VIP。PCCW（香港）/HKT可直连的国内骨干网：AS4134、AS4809、AS4837、AS9929、AS58453我们平时接触PCCW的机会很多，PCCW也有一个负责国际优化的网络PCCWG （G=Global），我们平时遇到的商家一般接入的都是PCCW（非含G的网）。其实PCCW的效果在平时是被夸大的，就算是线路可以直连实际综合连接效果也仅仅是一个平均水平。电信163（AS4134）到香港PCCW是否直连看本地电信网络是否有自己的AS号，比如北京电信的AS4847城域网，上海电信的AS4812城域网等。一般来说，如果该地网络有自己的城域网AS号专门管辖，除非商家有特别优化，那么一般到香港PCCW不直连，否则如果是直接位于AS4134上一般会直连。电信网络到PCCW一般只有北京和广州两个汇聚层可达，上海汇聚层不可达，高峰丢包较高，速度不理想。联通169（AS4837）联通到香港PCCW可能绕美，原因和电信部分相同，不再赘述。直连的情况下，联通到PCCW效果要远远好于电信，处于可用的状态。联通A网（AS9929） 网络质量基本是这么多网络里面连接到PCCW最好的，延时抖动也是最低的。但是9929的价格比CN2都要贵上好多倍，一般没有点钞能力是用不上的…移动的CMI（AS58453），如果没有商家优化，移动会随机把路由发往美国、日本、香港三地，以实现流量平衡，在用户看来，这就导致延时时高时低，非常不稳定，不推荐移动使用。同时，HKT隶属于PCCW，所有的国际出口都是走PCCW/PCCWG的。HKT因为可以走上PCCWG和德国地区直连，所以也被称之为打机神线。但是普通的HKT家宽/静态根据段不一样，联通169可能绕韩国KT，也有可能直连（联通9929通过PCCW与HKT互联）。CHT（香港）可直连国内骨干网：AS4134、AS4837、AS58453CHT即中华电信，为中国台湾的第一大运营商，拥有2大骨干网（CHW「 HINET」、TWGATE），我们通常说的Hinet即为CHW网络，CHW与TWGATE的关系可以参照电信163和CN2的关系。事与愿违，不知道开始，电信163骨干网到CHW网络的效果急转直下，无论是低峰还是高峰的下载速度都只能用惨淡来形容。所以除非你有业务需求，否则我不推荐你把个人网站放在CHW下，高昂的成本价格现在无法匹配上其延时和速度，是个性价比很低的选择。相比于电信163的拉垮表现，联通169的表现就漂亮的多，差不多的延时却有着更低的丢包，更高的峰值速度。但是鉴于该地区很高的主机售价，如果你是一个联通用户，CHW也未必是最佳的选择。也别对移动CMI抱有太大的期望，在低峰和高峰表现截然不同，高峰常常极度拉垮，上面的Telstra好歹还是有速度，这个是真的一点速度都跑不出来，不推荐。中国台湾(TW)常见运营商：HiNet、TFN（台湾固网）、SeedNet、TaNet（台湾学术网络）、HomePlus（中嘉宽频）常见数据中心：TWIX这里只说下Hinet，因为其他不了解甚至没见过...HINET可直连国内骨干网：AS4134、AS58453、AS4837其中 电信 和 联通 延迟都明显要比移动高一些。HiNet是中华电信（CHT）的一个品牌，也是全台湾最大的宽带提供商。目前台湾地区的主流流媒体解锁都是用了HiNet动态IP（家宽）以及静态IP（商宽、IDC）来解锁的。HiNet拥有整个台湾地区最大的电信骨干网，也是国内出口流量最大的ISP。CHT另拥有一张TWGate的网络，专注国际互联，其性质相当于中国电信的CN2。日本(JP)常见运营商：NTT、IIJ、KDDI、BBTEC、Telstra、PCCW、BGP.NET常见数据中心：JPIX、BBIX、EIEHND（Equinix Internet Exchange Tokyo）常见下游：Cloudflare、Amazon、Azure、Google、M427、xTom（搬瓦工是他的下游）日本的宽带业务竞争激烈，导致ISP提供商不得不杀出更低的价格来吸引客户，但是往往事与愿违——用户的口碑却更糟糕了。比如，和阿里巴巴合资的SoftBank（软银）公司创立的ISP服务商——BBTEC，看起来是一个不错的选择，实际晚高峰网络拥堵，体验很差劲。不仅是家宽，商宽乃至服务器机房，接入一条ISP线路的成本价格都不菲，况且很多日本IDC只对日本本国居民提供服务，所以催生了很多代办业务，最有名的就是樱花机房的服务器代办服务。往往只有这些对本土开放的IDC才有可能是原生IP（可以解锁当地的众多流媒体、游戏和网站）。NTT可直连国内骨干网：AS4134、AS4809、AS4837、AS9929、AS58423日本作为NTT的大本营，几乎全国的宽带服务提供商都有NTT的踪迹。因为NTT的骨干网覆盖了日本几乎所有能够覆盖到的地区。关于日本NTT，我想在文中说明的实在太多了，限于篇幅，我还是精简一下。NTT和国内ISP互联时间很早，在2000年后，NTT和当时的网通互联，互联出口设在上海和北京，并在上海和北京分别建设NTT的PoP节点（少数国外ISP将PoP设在国内的案例）。值得一提的是，但是这是目前国内直连日本NTT延时很低且很稳定的渠道，CN2到日本NTT都干不过它，根据实测，目前NTT-9929的速度基本取决于用户接入的9929的带宽速度。中国电信163和日本NTT之间的扩容就勤快多了，电信还在日本东京设立了PoP方便和日本本土ISP快速互联。听起来很美好是吗？但是这不妨碍电信163和日本NTT之间日常大爆炸（里面大部分都是被巨量的DDOS流量打崩的）。IIJ可直连骨干网：AS4134、AS4837、AS58423中国电信的163与IIJ的互联是通过电信在东京的PoP实现的，国内可以通过三大汇聚层轻松访问PoP节点。互联的网络质量远好于和NTT的质量。IIJ是电信163用户造访日本网站最好的线路之一，目前已经胜过软银，不考虑高峰丢包和延时抖动，是性价比之选。中国联通169与IIJ的互联方式和电信几乎一样，但是综合来看要好于163与IIJ互联的质量。提供IIJ接入的IDC价格比较亲民的很多，如果不愿意接受软银的高价位的话，那就上IIJ吧。目前移动和IIJ的互联已经通过东京移动的PoP来完成，故移动到日本IIJ不再绕香港而是通过NCP海缆直连东京的PoP后与IIJ完成互联，上海移动到东京IIJ参考延时为45ms（网上查的）。综上，IIJ是日本地区对我们比较友好的，也是价格相较于其他三家比较实惠的一家ISP，如果没有太小众化的需求，上国内走IIJ的VPS是很省心的选择。BBTEC（软银）可直连骨干网：AS4134、AS4837、AS9929、AS58423BBTEC（软银）其实是近几年才被我们注意到的一家ISP，在上海地区设有PoP并与电信163和联通169/9929互联。该线路一直被称之为联通到日本最好的线路之一。想要补充一点的是，9929早期和软银并没有直连Peer，而是借助4837（联通169）作为跳板实现的。而近期在路由测试中，我们可以清楚地看到软银和9929已经在上海PoP实现互联，但是在BGP ToolKit上都未显示2者有任何形式的互联，基本可以判断是Private Peer。电信163到软银延时相比于NTT属实较低，但是却同样跑不出什么速度来，延时最初是日本御四家里最低的，但是后来因为使用人数的增加，延时逐渐不如IIJ。联通169到软银的延时则相对不稳定，取决于去程走上海口和北京口，通常BBTEC回程经由自己的上海POP与联通互联。尽管联通和软银互联的优势已经不如以前，但是目前仍旧是联通到日本最好的线路之一。联通9929到软银的延时稳定，互联速度也取决于用户接入的9929带宽速度。如今，移动已经在日本的东京设立了PoP，所以从回程看，除了广州移动还是继续走香港CMI，其余均在日本就Peer，并由移动自己的骨干网负责流量回国承载。目前去程依旧全部绕香港CMI，这也导致北方移动延时的升高。总体来说，软银对北方移动不友好。新加坡区域常见运营商：NTT、Singtel、Telstra、StarHub、MyRepublic、PCCW(G)、Cogentco、HE、Tata、CMI、CUG、BGP.NET、SG.GS常见数据中心：SGIX、EIESG（Equinix Internet Exchange Singapore）下游：OVH、Cloudflare、Google、Amazon这里还是主要说一下NTTNTT（新加坡）可直连国内骨干网：AS4134、AS58453正如你所见，NTT在亚太地区无处不在~ 所以我们一般把NTT视作亚太地区ISP的标杆，这已经成为了事实上公认的标准。在新加坡，NTT也拥有巨量的骨干资源，轻松连接新加坡所有的本地ISP。NTT也有多条新加坡至日本的海底光缆所有权/使用权，所以NTT可以借新加坡作为跳板，以此连接马来西亚、菲律宾、印度尼西亚、泰国、越南、缅甸、柬埔寨、印度等国。中国电信163与2020年和NTT在新加坡正式建立互联，即意味着新加坡NTT从即日起无需绕行日本再与163骨干网互联，但是情况变得更加糟糕，因为新加坡地区的中国电信163和NTT互联宽带很小，所以几乎全天都处于被塞满的状态，延时异常偏高，丢包率极大，因此非常不推荐使用163连接新加坡地区的NTT。移动的CMI在新加坡有自己的PoP，同时在当地就可以和NTT互联，因互联宽带很大，所以目前没有看到被塞爆的情况，移动用户目前访问新加坡地区资源的主流渠道就是通过新加坡PoP。联通9929和联通169目前都不能直连新加坡NTT，请详见上面的日本NTT。韩国常见运营商：KT、SKT、LG （绕路的ISP:NTT、PCCW、Telstra Global 绕日绕港绕新加坡 故不测试）常见数据中心：KINX常见下游：Moack、Oracle、Cloudflare、Amazon、Azure韩国本土网络发达，除了三大ISP以外还有地区性ISP，大陆地区前往韩国主要走TPE、APG、APCN-2、NCP四大海缆。国际路由差强人意，但靠着CDN也足够应付。但到中国大陆的带宽与路由不尽人意，绕路与直连汇聚层日常性堵塞层出不穷，丢包与抖动比较严重（虽然没有到163-NTT那么夸张）。同时韩国的互联网管理相对严格，购买上比较麻烦（建议别买，没啥必要）。这里还是只讲一下KT。KT可直连骨干网：AS4134、AS4809、AS4837、AS9929、AS58453KT（Korea Telecom），韩国最大电信运营商，市场占有率排名第一。英雄联盟里KT战队的赞助商，就是他，你如果打LOL就对这个名字很眼熟（以前粉，现在不粉了，我还是那个RNG粉丝）。目前电信163/CN2和韩国KT之间的互联是通过APG海缆完成的，因为APG海缆只在上海有登陆，所以目前前往韩国KT都是走上海出口。电信163至韩国KT的速度在Peer不被塞满的情况下单线程能跑100-200Mbps，晚高峰受限于汇聚层和Peer宽带的双重因素影响，速度受限比较严重。CN2虽然不用太担心汇聚层的拥塞问题，但是目前的Peer宽带依旧是比较主要的速度和延时等稳定性制约因素。联通9929与KT有互联，同样也是走上海出口。高峰期几乎无丢包，延迟极低，单看极限最低延迟逼近沪韩IPLC；可惜经常抖动，虽然幅度非常小。速度方面也属于跟日本ISP到9929一样，KT到9929的速度取决于用户接入的9929带宽速度。德国(DE)主打一个玄学...DTAG可直连骨干网： AS4134、AS4837、AS9929Deutsche Telekom AG ，德国电信，德国第一大ISP，T1级。旗下移动运营商T-mobile相比于DTAG更加知名。DTAG于AS4134和AS4837均有peer。同时也是AS9929上游。但延迟均200+起跳。电信163普通家宽会被强制丢包，而163plus能保证相对稳定延迟与相对较低的丢包联通169则取决于汇聚层是否拥塞。非拥塞状态则能保证网络质量。但是只限于北方地区的联通。南方地区的联通将会被无慈悲的绕美。AS9929依旧稳定发挥，甚至延迟优于AS4134 AS4837,但速度很勉强，几乎稳定80Mbps。Cogent CommunicationsCogentco由于在Traceroute上的细节写的过于清楚明白，以至于有一部分以为跳数越多越差人觉得Cogentco不行。虽然它也确实不太行…可直连骨干网：AS4134、AS4837、AS9929、AS58453。Cogentco,联通9929真正的互联主力……几乎绝大部分的欧美线路到9929都会被Cogentco宣告。以至于在欧洲会出现回程不走DTAG硬是跑Cogentco外加联通9929的NOC基本不会主动调整欧美路由。速度十分玄学，单线程在50Mbps摇摆，多线程却接近跑满。美国洛杉矶&圣何塞(US)洛杉矶和圣何塞是美西重要的面向亚太地区的互联网PoP中心，TPE海缆多从此处2点接入。中美之间的互联占据了出境流量很大的一部分，也是电信163出国的主要路径。HEHE，全称为 Hurricane Electric（飓风电气），目前是坐拥全球以Peer数量计算的最大IPv6骨干网的ISP，骨干网自治编号为AS6939。HE也提供免费的IPv6 Tunnel，以方便IPv4单栈的用户能够无障碍地访问IPv6网络。我们看到的亚太地区（香港、新加坡）的低价VPS产品线，几乎都一致地选择了HE作为唯一的互联网接入，而且接入的宽带并不大，平均1Gbps。但是哪怕是HE这样的ISP，在亚太地区的BGP Transit也颇为昂贵，这些商家为了能够有所盈利，在超低的VPS价格上，宽带上面必须大幅超售。可直连骨干网：AS4134、AS4837、AS58453电信163和HE在洛杉矶有10～20G的互联，平时鲜有出现较大的延时抖动，但是速度限制较为严重。联通169和HE的洛杉矶互联通常被视为在廉价互联里面很具有性价比的，相比于联通169和GTT的互联，和HE的互联质量就要好很多，很多用户也在尽可能选择更价廉物美的选择。CMI与美西的互联一向较差，并不具有较好的连通性，再加上HE和CMI的互联本身就炸的比较厉害，所以CMI就拉倒吧。GTTGTT，前身为Global Telecom and Technology，自1998年成立以来，在跨国电信业务上耕作至今。可直连骨干网：AS4134、AS4837、AS58453联通169在美西较大地依赖GTT的互联，导致延时相比正常美西延时高很多，速度并不乐观。电信163和GTT的互联却是出乎意料的好，根据SmokePing的结果，电信163和GTT的互联全天几乎不丢包，完全受限于汇聚层是否通畅。这就意味着只要使用高Qos的电信宽带就可以获得较好的速度。TeliaTelia是瑞典最大的电话和电信通讯公司，前身为瑞典电报局及芬兰电讯。现更名为Arelion，但目前在路由上的名称依旧是Telia。可直连骨干网：AS4134、AS4809、AS4837、AS58453Telia在美国、欧洲都有和电信163互联，总体来说是很中规中矩的线路。Cogent Communications可直连骨干网：AS4134、AS4837、AS9929、AS58453跟欧洲情况差不多。电信163在美西较大程度上依赖Cogentco的互联，天天爆炸。Verizon可直连骨干网：AS9929联通9929与Verizon的互联一言难尽，延迟不是最优，单线程速度也不是最优。高峰期单线程速度在50-70Mbps震荡。而多线程速度倒是能跑满，非常的玄学。有时候其他北美ISP到联通9929需要经Verizon转发，而被转发的速度就很难保证了。需要注意的是，欧洲/北美的网络情况跟亚太差异比较大。欧美的中小ISP大部分依靠的是IX互联或者机房托管的混合网络接入。虽然商业网络的价格比亚洲地区便宜，但至少对中国用户来说，很少再回程路由中遇见欧美的Regional T1或者高质量T1 ISP。

宝塔面板开启IPV6访问 宝塔面板开启IPV6访问1. 开启面板监听IPv6功能默认情况下，宝塔面板不会开启IPv6监听，尤其是在纯IPv6环境下。以下是开启IPv6监听的步骤：手动创建 ipv6.pl 文件在 /www/server/panel/data/ 目录下创建一个名为 ipv6.pl 的文件，并写入 True：echo "True" > /www/server/panel/data/ipv6.pl重启宝塔面板重启面板以确保IPv6监听功能生效：/etc/init.d/bt restart完成上述步骤后，面板可以通过IPv6地址访问。2. 开启网站IPv6支持在开启IPv6监听后，新创建的网站默认支持IPv6。如果需要为已存在的网站添加IPv6支持，需要手动修改网站的配置文件：进入网站配置文件打开宝塔面板，进入“网站”模块，选择对应网站的“配置文件”。修改配置文件将以下内容：listen 80; listen 443 ssl http2;替换为：listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2;

Debian / Ubuntu 手工添加 Swap 分区 Debian / Ubuntu 手工添加 Swap 分区准备工作首先，检查系统是否已有 Swap 分区：swapon -s或free -m如果没有返回结果或者free -m中Swap一列数值是0，则表示你的系统没有 Swap 分区。创建 Swap 分区我们可以使用fallocate命令创建一个 1GB 大小的 Swap 分区：fallocate -l 1G /swapfile如果这个命令无法使用，请安装 util-linux 包：sudo apt update && sudo apt install util-linux然后设置这个文件的权限：chmod 600 /swapfile然后激活 SWAP 分区mkswap /swapfile swapon /swapfile此时，你可以使用swapon -s或free -m命令查看 Swap 分区是否已经激活设置开机自启编辑 /etc/fstab 文件，添加以下内容：echo "/swapfile swap swap defaults 0 0" >> /etc/fstab调整系统内核 Swappiness 值Swappiness 是 Linux 内核的一个属性，定义了系统使用交换空间的频率。Swappiness 的值范围为 0 到 100，默认值为 60。较低的值会使内核尽量避免使用交换空间，而较高的值会使内核更积极地使用交换空间。查看当前 Swappiness 值：cat /proc/sys/vm/swappiness修改 Swappiness 值： 推荐将值设置为 10，以减少系统对 Swap 的依赖：echo "vm.swappiness=10" >> /etc/sysctl.conf使配置生效：sysctl -p关闭 Swap 分区如果需要关闭 Swap 分区，请按照以下步骤操作：停用 Swap 分区：swapoff -a编辑 /etc/fstab 文件： 删除 /swapfile swap swap defaults 0 0 这一行。删除 Swap 文件：rm /swapfile

MP4 和 MKV 文件修复教程 MP4 和 MKV 文件修复教程在使用视频文件时，可能会遇到文件损坏的问题，导致无法正常播放或编辑。本文将介绍如何修复损坏的 MP4 和 MKV 文件，方法简单易操作，使用一些常见的工具即可完成修复。MP4 文件修复工具准备recovery_MP4.exe：用于修复损坏的 MP4 文件。可以从以下链接下载：下载链接FFmpeg：用于合并音视频流。FFmpeg 是一个强大的命令行工具，通常在 Windows 系统中安装时，可以在软件安装目录下找到多个 ffmpeg.exe 文件。操作步骤准备文件将损坏的 MP4 文件重命名为 bad.mp4。若已有有效的 MP4 文件，可以用 FFmpeg 从中截取一小段，重命名为 good.mp4。执行以下命令：ffmpeg -ss 00:00:00 -t 00:00:30 -i input.mp4 -vcodec copy -acodec copy good.mp4这样可以生成一个 30 秒的有效视频片段。将文件放在同一目录将 bad.mp4、good.mp4、recovery_MP4.exe、ffmpeg.exe 放在同一个文件夹内。分析并修复进入命令行，执行以下命令：首先分析 good.mp4：recover_mp4.exe good.mp4 --analyze分析完成后，会生成 video.hdr 和 audio.hdr 文件。然后从 bad.mp4 中提取音视频流，生成 recovered.h264 和 recovered.aac：recover_mp4.exe bad.mp4 recovered.h264 recovered.aac合并音视频使用 FFmpeg 合并音视频流：ffmpeg.exe -r 30 -i recovered.h264 -i recovered.aac -bsf:a aac_adtstoasc -c:v copy -c:a copy recovered.mp4如果合并失败，您可以尝试使用 小丸工具箱 来封装生成的文件。MKV 文件修复工具准备FFmpeg：同样使用 FFmpeg 进行 MKV 文件修复，可以从 FFmpeg 官方网站下载并安装，或者在安装目录中找到 ffmpeg.exe。操作步骤准备文件将损坏的 MKV 文件重命名为 bad.mkv，并与 ffmpeg.exe 放在同一目录下。提取音视频流在命令行或 PowerShell 中执行以下命令：提取视频流：ffmpeg -i bad.mkv -an -sn -c:v copy -y -map 0:v:0 good.mkv提取音频流：ffmpeg -i bad.mkv -vn -sn -c:a copy -y -map 0:a:0 good.aac合并音视频使用 FFmpeg 将音频和视频流合并：ffmpeg -i good.mkv -i good.aac -c copy recovered.mkv无损转码为 MP4如果需要将 MKV 转换为 MP4，可以使用以下命令：ffmpeg -i recovered.mkv -codec copy output.mp4

Linux:扩展硬盘空间 /dev/vda1 显示 10GB 的分区，但实际使用空间只有 2.5GB，剩余的空间似乎没有被使用，且分区显示已经满了。这个问题可能是由以下几种原因导致的：1. 文件系统没有扩展虽然你有一个 10GB 的分区，但文件系统（如 ext4）可能没有正确扩展到整个分区的大小。文件系统的大小和分区的大小可能不一致，导致文件系统只使用了部分空间。解决方法：你可以使用 resize2fs 命令来扩展文件系统，确保它能使用整个分区的空间。首先检查文件系统类型：使用 lsblk -f 或 blkid 命令查看 /dev/vda1 使用的文件系统类型。sudo lsblk -f扩展文件系统：假设你的文件系统是 ext4，可以使用 resize2fs 命令来扩展文件系统到整个分区：sudo resize2fs /dev/vda1如果文件系统是 xfs，则可以使用 xfs_growfs：sudo xfs_growfs /dev/vda1检查文件系统大小：执行 df -h 命令确认扩展是否成功：df -h2. 分区表没有被更新如果你最近调整了磁盘大小或分区表（例如使用了 fdisk 或 parted 调整了磁盘分区），那么可能分区表已经更新，但文件系统的大小并没有自动调整。解决方法：可以使用 fdisk 或 parted 工具重新检查和调整分区表。查看当前分区：sudo fdisk -l /dev/vda调整分区大小：如果分区表没有正确显示 10GB 的大小，你可能需要重新创建分区（小心数据丢失，请确保备份重要数据）：使用 fdisk 删除 /dev/vda1 分区（不丢失数据，前提是没有更改分区的起始位置）。重新创建一个大小为 10GB 的分区，并使用 resize2fs 或 xfs_growfs 扩展文件系统。3. 系统或文件损坏如果在操作过程中系统或文件表出现损坏，可能会导致空间显示异常。在这种情况下，可以尝试使用 fsck 命令检查并修复文件系统。解决方法：检查文件系统：sudo fsck /dev/vda1这个命令会扫描并修复文件系统中的错误。4. 挂载问题如果 /dev/vda1 已正确扩展，但挂载的目录显示为 100% 已用，可能是因为某些目录（如 /tmp、/var）占用了大量空间，或者某些挂载点没有正确更新。你可以使用以下命令查看哪些目录占用了大量空间：sudo du -sh /* | sort -rh | head -20这将列出根目录下最大的 20 个文件或目录，帮助你找出空间被占用的原因。总结：检查并扩展文件系统：使用 resize2fs 或 xfs_growfs 命令扩展文件系统，以确保它使用整个 10GB 分区的空间。重新调整分区：如果分区表有问题，可以重新调整分区表。检查文件系统损坏：使用 fsck 检查并修复文件系统错误。