Linux 系统源切换工具 yum切换工具 很多时候是 源地址失效，或者网络不通，导致 yum 用不了，才需要换源。1、为什么很多时候必须更换 yum 源？CentOS7 刚装好，自带的是 官方源（国外）：1：国内访问国外服务器慢、丢包、超时服务器在海外，下载软件几 KB/s，甚至直接连接失败，yum install 卡死报错。换成阿里 / 清华国内镜像，速度几十上百倍。2：旧版本系统官方源下线《 最常见坑！》比如 CentOS7 在 2024 年已经停止维护（EOL），官方把软件包从 mirror.centos.org 迁移到 vault.centos.org。现象：yum 命令本身能运行，但是源地址 404，找不到包。这时候必须改 repo 里 baseurl 到 vault 地址，不然 yum 永远无法安装软件。3. 内网环境： 服务器不能上外网，必须换成本地光盘源 / 内网仓库源，外网源直接不可访问。一句话：yum 程序本身是好的，只是它读取的仓库地址不能用了，所以要换源。2、怎么更换yum很多小白不会手动切换yum，就算会手动更换yum也太麻烦而且有时候还容易出错，那咱就使用《爱意Web 一键切换yum脚本》他里面包括了很多yum地址，可以随意切换，而且轻易不会出错。一键切换yum脚本curl -fsSL https://storage.aiyiwl.com/api/yum_replace.sh -o yum_replace.sh && chmod +x yum_replace.sh && ./yum_replace.sh

利用ping命令检测网络连通性 在网络运维中，ping命令是验证目标主机可达性的基础工具，通过发送ICMP回显请求并接收应答，可快速定位网络故障。本文系统梳理了ping命令的跨平台使用方法、高级参数配置及结果分析技巧，并结合其他工具提供完整排查流程。基本操作Windows系统打开命令提示符：快捷键：按Win + R输入cmd回车。执行Ping基础检测：ping <目标IP或域名>示例：检测百度服务器ping baidu.com ## 输出示例： 正在 Ping baidu.com [124.237.177.164] 具有 32 字节的数据: 来自 124.237.177.164 的回复: 字节=32 时间=39ms TTL=49 来自 124.237.177.164 的回复: 字节=32 时间=38ms TTL=49 来自 124.237.177.164 的回复: 字节=32 时间=39ms TTL=49 来自 124.237.177.164 的回复: 字节=32 时间=39ms TTL=49 124.237.177.164 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 38ms，最长 = 39ms，平均 = 38msLinux/macOS系统打开终端执行Ping基础检测：ping <目标IP或域名>示例：检测百度服务器ping baidu.com ## 输出示例： PING baidu.com (110.242.74.102) 56(84) bytes of data. 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=1 ttl=47 time=26.6 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=2 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=3 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=4 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=5 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=6 ttl=47 time=26.6 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=7 ttl=47 time=26.6 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=8 ttl=47 time=26.6 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=9 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=10 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=11 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=12 ttl=47 time=26.5 ms 64 bytes from 110.242.74.102 (110.242.74.102): icmp_seq=13 ttl=47 time=26.5 ms高级用法持续监测系统命令示例停止方式Windowsping -t www.baidu.comCtrl + CLinux/macOSping google.com（默认持续）Ctrl + C指定发送次数系统命令示例Windowsping -n 5 www.baidu.comLinuxping -c 5 google.com调整数据包大小系统命令示例Windowsping -l 1000 www.baidu.comLinuxping -s 1000 google.com设置超时时间系统命令示例Windowsping -w 2000 www.baidu.comLinuxping -W 2 google.com结果分析关键指标解读1. 成功响应： 显示Reply from或64 bytes from，表示目标可达。 2. 丢包率计算： 丢包率 = (发送数 - 接收数) / 发送数 × 100% 示例： 发送10包收到8包 → 丢包率20%。常见问题定位现象可能原因请求超时目标不可达/防火墙拦截未知主机DNS解析失败/域名错误未知主机路径中存在路由环路结合其他工具排查路径追踪 / 路由追踪tracert baidu.com # Windows traceroute google.com # Linux ## Windows 输出示例： 通过最多 30 个跃点跟踪 到 baidu.com [124.237.177.164] 的路由: 1 <1 毫秒 <1 毫秒 <1 毫秒 10.0.0.1 2 6 ms 6 ms 4 ms 103.155.122.1 3 2 ms 2 ms 2 ms 172.24.254.25 4 <1 毫秒 <1 毫秒 <1 毫秒 172.25.1.57 5 * * * 请求超时。 6 4 ms 1 ms 1 ms 61.14.203.206 7 * * * 请求超时。 8 * * * 请求超时。 9 5 ms 5 ms 5 ms 103.239.176.121 10 * 6 ms 6 ms 219.158.6.61 11 6 ms 6 ms 6 ms 219.158.4.109 12 * 7 ms 7 ms 219.158.3.17 13 38 ms 38 ms 38 ms 219.158.108.241 14 * * 39 ms 219.158.110.58 15 * * * 请求超时。 16 43 ms * 43 ms 202.97.17.101 17 * * * 请求超时。 18 49 ms 49 ms 50 ms 27.129.17.86 19 * * * 请求超时。 20 49 ms 49 ms 49 ms 222.222.85.106 21 * * * 请求超时。 22 * * * 请求超时。 23 * * * 请求超时。 24 * * * 请求超时。 25 * * * 请求超时。 26 50 ms 50 ms 49 ms 124.237.177.164 跟踪完成。 ## Linux 输出示例： traceroute to google.com (74.125.136.138), 30 hops max, 60 byte packets 1 103.155.122.1 (103.155.122.1) 8.848 ms 9.163 ms 9.481 ms 2 172.24.254.29 (172.24.254.29) 3.509 ms 3.921 ms 4.324 ms 3 172.25.1.49 (172.25.1.49) 0.439 ms 172.25.1.53 (172.25.1.53) 0.441 ms 172.25.1.49 (172.25.1.49) 0.482 ms 4 157.238.230.82 (157.238.230.82) 0.624 ms 0.647 ms 0.589 ms 5 * * * 6 ae-26.a00.chwahk03.hk.bb.gin.ntt.net (129.250.2.183) 1.485 ms ae-18.a00.chwahk03.hk.bb.gin.ntt.net (129.250.2.149) 1.598 ms 1.667 ms 7 * * * 8 72.14.210.12 (72.14.210.12) 1.834 ms 1.763 ms 1.830 ms 9 * * * 10 142.251.244.224 (142.251.244.224) 1.583 ms 142.250.58.82 (142.250.58.82) 4.014 ms 216.239.47.16 (216.239.47.16) 1.729 ms 11 216.239.42.120 (216.239.42.120) 1.756 ms 192.178.99.8 (192.178.99.8) 2.416 ms 216.239.46.74 (216.239.46.74) 2.558 ms 12 74.125.251.11 (74.125.251.11) 2.255 ms 216.239.63.216 (216.239.63.216) 2.127 ms 2.211 ms 13 108.170.236.244 (108.170.236.244) 50.433 ms 142.251.49.205 (142.251.49.205) 52.788 ms 54.353 ms 14 172.253.75.65 (172.253.75.65) 143.348 ms 142.250.213.195 (142.250.213.195) 141.266 ms 142.250.213.211 (142.250.213.211) 141.798 ms 15 192.178.96.163 (192.178.96.163) 149.438 ms 192.178.96.169 (192.178.96.169) 150.956 ms 142.251.69.204 (142.251.69.204) 169.832 ms 16 142.251.196.58 (142.251.196.58) 169.782 ms * 192.178.255.155 (192.178.255.155) 170.265 ms 17 142.251.61.212 (142.251.61.212) 199.886 ms 142.251.241.234 (142.251.241.234) 201.969 ms 201.894 ms 18 142.251.51.106 (142.251.51.106) 202.239 ms 108.170.231.149 (108.170.231.149) 200.775 ms 142.251.51.8 (142.251.51.8) 196.787 ms 19 108.170.228.163 (108.170.228.163) 201.638 ms 216.239.48.109 (216.239.48.109) 203.257 ms 209.85.247.93 (209.85.247.93) 203.478 ms 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 yr-in-f138.1e100.net (74.125.136.138) 196.147 ms 197.166 ms 199.079 ms 注意事项1. 权限要求： Linux下部分参数（如-f洪泛测试）需root权限。 2. 防火墙影响： 目标主机可能禁用ICMP响应，导致Ping失败但实际网络正常。 3. 网络负载： 大包或高频Ping可能被误判为攻击，需谨慎使用。

Linux Ubuntu 云服务器启动失败！ 云服务器启动失败故障提示：[5.877137] async_tx: api initialized (async) [6.013920] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes一直卡在这里，启动不了。 1：进入【Linux 救援系统】2：挂载原系统盘并检查日志# 1. 查看磁盘分区（确认你的系统盘，通常是 /dev/vda1 或 /dev/vdb1） lsblk # 2. 创建挂载点并挂载根分区（假设是 /dev/vda1） mkdir -p /mnt/root mount /dev/vda1 /mnt/root # 3. 查看系统日志最后几十行，找出卡住前的具体报错 tail -100 /mnt/root/var/log/messages # 或者查看 dmesg 日志 tail -100 /mnt/root/var/log/dmesg关键：日志中如果出现 I/O error、EXT4-fs error、XFS: metadata I/O error 等，说明文件系统损坏。如果出现 Failed to start ... service 或 Timeout，则是某个服务启动失败。3：根据系统日志判断问题# 最后10行日志 Jun 17 12:08:30 Rescue-AiyiWL8721418951 dracut[1299]: *** Creating image file '/boot/initramfs-4.18.0-358.el8.x86_64kdump.img' *** Jun 17 12:08:30 Rescue-AiyiWL8721418951 dracut[1299]: *** Creating initramfs image file '/boot/initramfs-4.18.0-358.el8.x86_64kdump.img' done *** Jun 17 12:08:32 Rescue-AiyiWL8721418951 kdumpctl[1014]: kdump: kexec: loaded kdump kernel Jun 17 12:08:32 Rescue-AiyiWL8721418951 kdumpctl[1014]: kdump: Starting kdump: [OK] Jun 17 12:08:32 Rescue-AiyiWL8721418951 systemd[1]: Started Crash recovery kernel arming. Jun 17 12:08:32 Rescue-AiyiWL8721418951 systemd[1]: Startup finished in 2.958s (kernel) + 11.477s (initrd) + 1min 74ms (userspace) = 1min 14.510s. Jun 17 12:08:40 Rescue-AiyiWL8721418951 systemd[1]: systemd-hostnamed.service: Succeeded. Jun 17 12:08:54 Rescue-AiyiWL8721418951 chronyd[803]: Selected source 94.237.79.110 (2.centos.pool.ntp.org) Jun 17 12:09:01 Rescue-AiyiWL8721418951 kernel: EXT4-fs (vdb1): warning: mounting fs with errors, running e2fsck is recommended Jun 17 12:09:01 Rescue-AiyiWL8721418951 kernel: EXT4-fs (vdb1): mounted filesystem with ordered data mode. Opts: (null)日志最后两行是关键：vdb1 是一个数据盘（或系统盘），它是 EXT4 文件系统。系统在救援模式下强行挂载了这个有错误的分区，这通常是为了让你能进去抢救数据，但带着错误启动，正是原系统卡住进不去的原因。4：修复方案你现在就在救援系统里，正好可以修复。执行以下命令：第一步：卸载问题分区umount /dev/vdb1如果提示 target is busy（分区忙），先执行 fuser -km /dev/vdb1 强制踢出进程，再执行卸载。第二步：执行文件系统修复e2fsck -y /dev/vdb1-y 参数会自动回答“是”来修复所有问题，不用一直按确认。这个过程可能需要几分钟到十几分钟，耐心等待它跑完。如果有大量错误修复输出，是正常的。第三步：检查主系统盘（vda1） 虽然日志报错的是 vdb1，但你的系统盘通常是 vda1（从之前的启动日志 vda: vda1 vda14 vda15 可以看出）。为了防止主系统也有潜在问题，建议也检查一下：umount /dev/vda1 # 如果已挂载就先卸载 e2fsck -y /dev/vda1第四步：重新挂载测试 修复完成后，可以重新挂载看看是否正常：mount /dev/vdb1 /mnt # 假设挂载点存在 ls /mnt # 如果能正常列出目录，说明修复成功5：完成后重启1：在魔方云控制面板，点击 “退出救援系统”（或“重启至正常系统”）。2：实例会自动重启，这次应该能正常进入系统了。如果修复后还是进不去说明除了文件系统错误，可能还有其他问题：可能是根分区（vda1）也有类似报错， 但日志里没显示。请务必也对 vda1 执行 e2fsck -y /dev/vda1。可能是启动配置文件损坏。 修复后，可以在救援模式下挂载根分区，检查 /mnt/etc/fstab 文件，看是否有错误的分区挂载条目。如果 e2fsck 提示“无法修复”或出现大量“坏块”， 说明磁盘可能物理损坏，那就只能备份数据后重装系统了。补充建议修复完成后，进入原系统后第一时间备份重要数据，因为文件系统报错往往是磁盘寿命下降的早期信号。如果你不熟悉命令行操作，魔方云通常也有工单支持，可以把这段日志发给客服，他们会协助你进行修复。你先按 e2fsck 步骤操作，把修复过程的输出结果发给我，如果有新的报错我再帮你分析。

Linux 救援系统，怎么查看原系统盘文件 系统文件损坏进不去系统，但是还有重要文件要备份，怎么办？不用害怕跟担心，咱直接进入 “救援系统” 进行操作！进入 “救援系统” 还是看不见原系统的文件怎么办，跟着我继续操作！操作1：查看磁盘信息：执行 fdisk -l 或 lsblk 命令，列出所有磁盘设备。通常，救援系统的盘是 /dev/vda，而你原来的系统盘会是 /dev/vdb。如果有多块数据盘，可以通过磁盘大小或分区类型来仔细辨别。比如，系统盘通常会有/boot和/（根）分区。2：创建挂载点：创建一个空目录作为挂载点，例如 /mnt 或 /datamkdir /mnt/old_system3：挂载系统盘：将识别出的原系统盘分区（通常是根分区，如 /dev/vdb1）挂载到刚创建的目录下。mount /dev/vdb1 /mnt/old_system4：验证挂载：执行 df -h 或 ls /mnt/old_system，如果能看到原系统的目录结构（如 /etc、/home 等），就说明挂载成功了。总结现在，你就可以像操作普通文件夹一样，通过 /mnt/old_system 这个路径来访问和操作你原来的系统盘了。常见的操作包括：恢复数据：将重要的网站数据、数据库文件等拷贝出来。修复系统：例如，chroot /mnt/old_system 切换到原系统环境进行修复，或者编辑 /mnt/old_system/etc/shadow 文件来重置root密码。修复文件系统：如果文件系统损坏，可以执行 xfs_repair 或 fsck 等命令进行修复。

宝塔计算任务 PHP 致命错误 中文提示： PHP 致命错误：Composer 在您的平台上检测到问题：您的 Composer 依赖项需要 PHP 版本“>= 7.2.5”。而您当前运行的版本是 5.6.40。错误发生在 /www/wwwroot/cloud.aiyiwl.net/vendor/composer/platform_check.php 文件的第 25 行严重错误：Composer 在您的平台上检测到问题：您的 Composer 依赖项需要 PHP 版本“>= 7.2.5”。而您当前运行的版本是 5.6.40。错误发生在 /www/wwwroot/cloud.aiyiwl.net/vendor/composer/platform_check.php 文件的第 25 行英文提示： PHP Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.2.5". You are running 5.6.40. in /www/wwwroot/cloud.aiyiwl.net/vendor/composer/platform_check.php on line 25Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.2.5". You are running 5.6.40. in /www/wwwroot/cloud.aiyiwl.net/vendor/composer/platform_check.php on line 25解决教程方案一：使用宝塔 bt 命令（推荐）1：通过 SSH 工具连接服务器，确保使用 root 权限。2：在命令行中输入 bt 并按回车。3：在弹出的菜单里，输入 16 并按回车，这会进入“切换PHP-CLI版本”功能。4：系统会列出已安装的 PHP 版本（例如 74 对应 7.4），输入 7.4 对应的号码并按回车。5：完成后，建议重启 SSH 会话（关掉再连一次）或运行 source /etc/profile，让设置完全生效。最后输入 php -v 验证一下版本。方案二：手动修改软链接（备选）如果你不想用 bt 命令，也可以通过修改系统软链接来实现：1：SSH 登录服务器。2：依次执行以下命令，将 PHP 7.4 设置为系统默认：rm -f /usr/bin/php ln -sf /www/server/php/74/bin/php /usr/bin/php(注：如果你的版本是 7.4，路径就是 /www/server/php/74；若是 8.0，路径则改为 /www/server/php/80)3：替换后，执行 php -v 确认生效。检查与清理切换完成后，强烈建议执行这几步收尾工作：1：重启 PHP 服务： 在面板的 软件商店 找到你切换到的 PHP 版本（如 PHP-7.4），点击 设置 → 服务，然后 重载配置 或 重启。 2：清除 OPcache 缓存： 在上述 PHP 设置页面，点击 安装扩展，找到 opcache，如果已安装，可以临时关闭再开启，或直接重启 PHP 服务来清空缓存。 3：验证 Composer： cd 到项目目录，执行 php -v 确认是 PHP 7.4，再执行 /www/server/php/74/bin/php /usr/bin/composer install。 4：检查 PHP 扩展： 在 PHP 7.4 的设置页面，检查项目所需的扩展（如 fileinfo、opcache 等）是否都已安装。总结操作的关键就是分离 Web 和 CLI 环境，并按需配置正确的软链接。考虑到 PHP 5.6 已在 2018 年底停止安全更新，存在严重风险。建议把默认 PHP 版本升级到 7.4，不仅解决了眼前这个报错，后续部署新项目时也更方便。切换成功后，网站就可以跑在兼容的 PHP 7.4 环境上了。如果在操作中遇到任何问题，或者切换后网站出现 502 Bad Gateway 之类的错误，随时告诉我，我来帮你进一步排查。