2026-04-28 22:11:39
我给自己定义“瞎折腾”应该很多次了！每次折腾完一件事之后，才会把整个折腾的过程撸一撸思路，这才会发现绕了太多太多的弯路而浪费了太多太多的时间。讲一讲这次我又是怎么样瞎折腾兰空图床上传失败的吧！
应该是大前天，我写老张随笔里需要上传一张图片到图床，传了N次都不行，要知道之前上传都是正常的，换了其他的存储方式也上传不了！好了，下面就是我的“骚操作”，开始了我的“瞎折腾”之路了！
兰空图床我是普通方式安装，在生成缩略图、图片处理以及发送邮件等等功能中，这些耗时任务都需要使用消息队列来执行，我们可以使用 php artisan queue:work 命令来运行消息队列。这块我是删了加、加了删，折腾了N次。
结果是可想而知的！图片上传还是失败！
为了能跟上“潮流”，我在3月20号的时候，把数据库mysql从5.7版本升到了8.0的，升级之后所有网站运行正常。期间在4月10号的时候还正常的上传过图片到图床。但是，自己的脑子还是跑气，还是把数据库给降级了。这次降级没有直接整体降级，而是给兰空图床单独配置了一个docker部署的Mysql5.7版。这次折腾docker部署的Mysql5.7版也是搞了半天的时间，Docker版的mysql部署好后，导入数据又是个问题了，又安装Navicat，远程到Docker版的mysql数据库，才把数据给恢复了！
结果是可想而知的！图片上传还是失败！
脑子跑气上头了！折腾起来不经大脑了！把数据库备份下，把网站、数据库重部删掉，下载网站源文件，从0开始安装，在用全新数据库的情况下再次测试图片上传，结果，结果，还是失败！把数据库恢复后再次测试，结果，结果还是失败。
人如果脑子一根筋了，谁劝也没有用，何况还没有人劝呢！在我的甲骨文破西上也是从0开始安装了兰空图床，上传图片成功！把数据库恢复，上传图片成功！
虽然把网站搬到甲骨文后上传图片正常了，但是甲骨文破西只是本时瞎折腾东西用的，放网站速度还是慢的。那只能再回来起点！
这次折腾，真的是静下心来了，想着，之前上传图片是正常的，而某个时间上传不成功，而网站环境、配置什么的又都没有修改过，那问题出在哪里了？请出我的“小张”，把网站日志交给小张分析，再把网站目录下的/storage/logs日志进行了分析，最终导致图片上传失败的原因找到了，想都不敢想！是服务器时间与标准时间不一致导致的上传失败！
日志分析得很清楚了，核心问题就是 服务器时间不对： 错误：RequestTimeTooSkewed
RequestTime: 20260421T084333Z (请求发起时间: 08:43:33 UTC) ServerTime: 2026-04-21T08:26:19Z (服务器认为的时间: 08:26:19 UTC) MaxAllowedSkew: 900000ms (15分钟)
两者相差约 17分钟，超过了 AWS S3 允许的 15 分钟偏差，所以 S3 拒绝了上传，返回 403 Forbidden。
解决方法：同步服务器时间 bash 查看当前服务器时间 date -u
同步 NTP 时间 timedatectl set-ntp true
或者手动安装 ntpdate 同步 ntpdate -b pool.ntp.org
同步完之后再上传就好了。
这个坑确实比较隐蔽——应用日志会报 403 Forbidden，但真正原因藏在 AWS 返回的 XML 错误信息里，提示 RequestTimeTooSkewed，指向时间偏差问题。
想不到是服务器时间与标准时间不一致，超过了S3的允许范围15分钟而导致拒绝上传！
唉，瞎折腾！瞎折腾！自己一直在瞎折腾！遇到问题不先理清思路，上去就是一通瞎折腾！结果是浪费了精力浪费了时间！就这件事而言，如果事前可以静下来，理理思路，根本就不会浪费这么多时间和精力！唉！以后遇事，还是得要先“想静静”吧！
2026-04-21 21:26:03
书接上回，清明节的时候一家去临沂玩了两天，头天去玩了《体验不佳的琅琊古城！》，晚上住在临沂市区的中维荣华大酒店，价格不贵环境也不错。半天时间把琅琊古城给逛完了，回到宾馆九点多，来临沂，那临沂炒鸡怎么能不吃呢，但是又怕被宰，所有从美团上找的“临师傅炒鸡”，离宾馆不远，步行十几分钟。点了186块钱的套餐，有临沂炒鸡另外配了四个菜，一家四口没有吃完。临沂炒鸡是真的好吃，在我们这里从来没有吃过这么好吃的炒鸡。
第二天早上睡到七点，到楼下酒店的自助餐厅吃了饭，这家早餐真的是非常的丰富，临沂炒鸡、蒙山全羊汤都有，但是味道差那么点意思。按我的计划，早饭后返程，顺路去马陵山玩的，但是老婆和孩子都不想去爬山，只得选择了“窑湾古镇”。
听同事说过窑湾古镇是免费的，但是到了地方却收了60块钱每人的门票钱，说是这两年才开始收的。好吧，收就收吧，只要好玩就行。哪不知！！
窑湾古镇不大，我们从十一点入门到出来，一共是花了一个半小时，全都是像上图那样的商业街。商铺里都是卖一些常规的小玩意，一点点新意都没有。如果说窑湾古镇的门票是60块钱的话，那南京夫子庙要收费的话，门票至少得要四五百块钱了。
唯一有点“新意”的就是这些油炸河鲜了，靠山吃山靠水吃水，在其他景区这类油炸河鲜还是不常见。买了一份油炸小河蟹15块钱，味道非常的我噻！好吃！
这座界碑楼应该是窑湾标识性的建筑了，建在宿州和邳州的交界处，有界牌详细介绍。
特别要吐槽的就是，不少小院门口标注了“窑湾必逛”的标识，像什么山西会馆、吴家大院，进去一看，真的只是“院”，里面空空荡荡什么也没有。
窑湾古镇，真的没有“古”的地方！只是逛逛商业小商铺罢了！
2026-04-16 10:41:23
我的办公电脑安装是三网口的网卡，一网口连接外网，而另外两个网口给虚拟机使用，用来连接内网。这样的好处是遇到紧急的情况可以不需要再跑到办全室来办公，可以在家里直接远程办公室电脑而达到连接内网的效果。
系统安装好到目前为止已经使用快五年时间了，也不知道从何时起，经常遇到QQ、微信可以正常使用，而网页打不开的情况。这样情况是电脑开机后，网页可以打开，不知道什么时候，网页打不开了，可能再过个把小时十几分钟，网页又可以正常打开了，反反复复。QQ微信正常可以连网，而网页打不开，正常的解决模式都是DNS或是问题题，因为QQ微信是用的直接IP连接，不依赖DNS默认网关。而浏览器则需要依赖于DNS，所以就会遇到“打不开网页，但是聊天却正常的情况”。
是的，可能大家都是这么认为的，我也是这样认为的，所以当出现这样的问题后，就一直在折腾着DNS和网关。不管是手动设置IP、网关、dns还是自动获取，问题依然会存在。后来通过度娘了解，下载了“360断网工具箱”，每次遇到网页打不开的情况就用“360断网工具箱”来进行修复，每次360断网工具箱检测的结果都是“HOSTS异常”，但是，并不是每次都可以修复成功。这个问题一直困扰我许久许久，估计至少有一年多时间。
后来kimi、豆包、deepseek出来后，也向这几位AI请教过，得到的答案和百度出来的结果差不多，都是DNS问题。没办法，将就着用吧，所以“360断网工具箱”是我每天打开次数最多的软件。
openclaw我都部署了两三个月了，我给我的openclaw起名叫“小张”，虽然“小张”是个犟种，但是还是给我解决了很多问题。之所以没有让“小张”帮我解决这个网络问题，我是想着连kimi、豆包、deepseek都解决不了，那“小张”也就解决不了吧！今天报着试试的心态，让“小张”解决来，结果三行命令找到问题的根源，三行代码解决问题。
我提出的问题是：我的电脑安装三个网卡，其中一个连接外网，另外两个分配给虚拟机连接内网使用，都是自动获取IP地址。QQ和微信可以正常使用，但是经常打开不了网页。
而“小张”经过初步判断就找到了问题的根源：
根据你描述的情况，我初步判断是多网卡路由优先级问题：
QQ/微信用的是直接 IP 连接，不依赖 DNS 和默认网关，所以还能用
浏览器依赖 DNS 和默认路由，路由冲突时就会"打不开网页但聊天正常"
把命令结果发我，我帮你具体分析是哪个网卡的路由优先级出了问题，以及怎么修。
第一步：打开命令提示符（CMD） 按 Win + R，输入 cmd，回车
第二步：逐条执行以下命令，后，把结果反馈给“小张”
ipconfig /all
route print
netsh interface show interface具体命令运行结果就不贴出来了，就直接贴出“小张”的分析报告吧！
找到根本原因了！路由表有严重问题。问题确认：三条等优先级默认路由
三个默认网关 metric 完全相同（都是35），Windows 会在这三条路之间负载均衡。问题在于：
192.168.1.1 和 192.168.2.1 是内网 VM 的网关，不走公网
你大约 1/3 的公网流量会走到这两个内网网关，导致网页打不开
QQ/微信部分流量碰巧走了 Tailscale（metric 5，优先级极高）或正确的外网网卡，所以能通
修复方案：把外网网卡（以太网/Realtek）的 metric 调低，让它优先。
netsh interface ipv4 set interface "以太网" metric=20
netsh interface ipv4 set interface "以太网 2" metric=50
netsh interface ipv4 set interface "以太网 3" metric=50在win界面个修改方法是：控制面板 → 网络和共享中心 → 更改适配器设置；然后：右键点击对应的网卡（以太网/以太网 2/以太网 3）→ 属性；双击 Internet 协议版本 4 (TCP/IPv4)；点击 高级去掉 "自动跃点" 的勾，输入自定义跃点数；确认一路确定。（跃点数数字越小超优先）
提到“接口跃点数”，我很确定的说，我在做系统的时候设置过，绝对设置过，保证设置过，但是后来不知道什么原因跃点数变成自动获取变成一样的了。出现问题也没有去想“接口跃点数”而一直在折腾DNS。
唉，困扰一年多的问题终于解决了！还是有“小张”好。
其实，这个问题如果静下心来仔细思考的话，应该可以轻松解决，但是却陷入了“常规思维”！现实中很多事情都是这样，明明问题很简单，却跳不出“常规”！
2026-04-08 21:59:18
提到琅琊古城，不少人可能认为是安徽滁州的琅琊山，其实琅琊古城坐落在山东的临沂，“纯人工”打造的旅游景点。
今年我们江苏第一次放春假，和清明连在一起也就是6天的假期。儿子高中不放春假，所以我们家的出游计划便安排在的清明期间了。
4月4号早上睡到六点半，也算是自然醒了，洗漱后到一家四口整理好东西开车到外面吃了点早饭，七点半出发，两个半小时到达临沂的中维荣华大酒店。外出游玩住酒店，我一般会选择连锁酒店或是当地比较有名一点的酒店，这样基本上不会踩坑。
这家酒店虽然还是十几年前装修的风格，但是档次还是非常不错，价格也不是太贵，亲子套房也才是五六百一晚还包含第二天的早餐。特别是第二天的自助早餐，品种是相当的丰富，连临沂炒鸡、蒙山羊杂汤都有。
中午酒店外面随便应付了一口，吃了我认为最最为难吃的酸笋炒鸭掌。鸭掌上面的厚皮都没有去掉！一盆菜，基本上没有动筷子。
下午一点到达琅琊古城，周边的配套还是不完善的，车停在东门对面的一个大院子里，车一过那个灰呀！
从宣传上可以知道，琅琊古城是座“演艺之城”，除了游玩之后就是看演出。但是必须要吐槽的地方就是在景区入口的服务台并没有找到当天的节目演出时间单，也可能清明假期人太多把节目单拿完了。三个大的演出有两个是收费的《国秀琅琊》和《国士捍山河》，我们选择的是《国秀琅琊》的套票，而《火秀》是免费的，但是也得要扫码预约。
更要吐槽的地方是公众号上小的演出时间和现场显示屏的时间对应不上去，可能是公众号内容长时间没有更新。所以想看小的演出只能是靠运气去“撞”。一块舞台周边坐满了人，等着演出，结果演出时间都过了二十来分钟了也没有见表演的人来，问了保安才知道根本就没有演出。
尝了下山东有名的“煎饼卷大葱，其实也就和我们这的卷饼一样，只不过是多包了一段大葱在里面。
不得不说《国秀琅琊》的室内演出真的很震撼！舞台效果是超级的棒，所以不少人称是全国室内演出的天花板。
而免费的《火秀》演出我们就没有看到着，我们赶到火秀表演场地再预约，只有晚上近十一点的场次了，需要等的时间太长，放弃！
当然也有值得点赞的地方，景区里有不少这样的“暖心小站”，免费提供白开水、绿豆茶、姜茶。每隔一段距离就有一个这样的暖心小站，为很多老人、幼儿提供了方便。
总体来说，如果来琅琊古城想纯游玩，真的不值得来，都是“纯人工”打造的，真的没有什么看头，值得看的也就是大大小小的演出。而想看这些演出，那来之前必须要做好功课，把每场演出时间把握好，能做到边游玩边看演出，这样才算是完美！
2026-04-04 01:18:09
按目前《目前老张博客服务器搭配方案！》，把老张博客还是搬回了CloudCone。酷鸭数据香港这台VPS，因为线路好配置也高，只放个小博客有点性能过剩了，准备把openclaw安装上去，让我的“小张”搞一些项目！如果手里没有好性能、好线路的机器，酷鸭数据真的是不错的选择！
目前老张博客的服务器搭配是:访客 → 瓦工 Megabox(1panel 反代+WAF) → CloudCone(宝塔+WordPress)，也就是在前天，有垃圾评论我准备拉黑IP地址的时候才发现，这个家伙的IP显示是我的瓦工 Megabox地址。出现这样的问题有两种可能，一是瓦工Megabox反代时没有把真实 IP 传递给 CloudCone，二是瓦工Megabox传递了真实IP但是 CloudCone 端的 WordPress 没有正确读取这真实IP。
在瓦工Megabox的 1panel 中，找到你的反向代理配置，添加以下 headers，具体步骤如下，并添加以下代码。注意，检查下，如果代码已存在，就不要再加了！经过检查，1panel的反向代理配置已经很完善了！
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
经过第一步后，发现wordpress还是没有能正确的获取到访客的真实IP。我又检查到我的“老张随笔”是可以正确获取的访客真实IP的。那问题就是出在WordPress的配置上了。打开WordPress根目录下的 wp-config.php，在 <?php 之后第一行添加下面的代码
// 获取真实 IP（反代场景）
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ip_list = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
$_SERVER['REMOTE_ADDR'] = trim($ip_list[0]);
} elseif (isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}OK了，至此，WordPress就可以获取到访客的真实IP了！你学废了吗！
2026-03-31 10:37:43
老张不是在搬博客，就是在搬博客的路上！不过这次搬完之后，就稳定不搬了！安心用酷鸭数据的香港VPS了！不折腾了！
《目前老张博客服务器搭配方案！》，根据这个方案是：访客→中转机：瓦工megabox（1panel反代）→落地机：CloudCone（宝塔部署WordPress）。虽然看着这么长的一串，配置起来真的不麻烦，而且速度、性能、安全等几个方面都得到了保障。
经过这一段时间的使用，我却遇到了一个无疼无痒的问题，就是直接评论文章时提交所需时间正常，一般情况下是一两秒钟，而回复评论至少二三十秒才可以提交成功，有时会超过一分钟。遇到问题就需要解决问题嘛，折腾呗。
这一点就可以排除，因为我压根就没有安装反垃圾评论插件。另外一点理由就是只有回复评论时提交才会卡，直接评论文章是正常的。
我的服务器搭配是使用瓦工megabox做中转机进行反代的，比正常访问多走了一个服务器，这点可能造成延迟。于是，我把中转机反代取消，域名直接解析到CloudCone的服务IP，结果问题并没有解决。
正常评论文章提交时间一两秒，因为“有人发表评论时”我没有选，只是设置了"如果有人回复评论时，请通过电子邮件通知”。那问题就很明显了，就是“评论邮件通知”的问题了！
我使用是小胡修改过的主题，评论邮件通知是主题自带的，没有去深研，先进行测试先吧！
在服务器上执行以下命令，测试邮件发送是否正常，结果显示连接正常，并没有超时或是很慢的情况。那就是说明smtp是通的！
# 测试服务器能否连接邮件服务器
timeout 5 telnet smtp.qq.com 465
# 或者
timeout 5 telnet smtp.163.com 465既然 SMTP 是通的，要么邮件是异步发送的（不阻塞主流程）、要么评论提交时的处理逻辑和回复邮件的逻辑不同。因为评论邮件通知不是插件而是主题集成的，就必须要分析主题代码，工作量大，等有时间再交给AI折腾吧！
因为CloudCone和酷鸭数据的两台服务器我都是部署了宝塔，博客搬家是真TM的方便，两三分钟，把博客再搬回到酷鸭数据的香港服务器上，再进行回复 评论测试，你猜怎么着！回复评论提交时间只需要一两秒了！
感觉这是件很玄幻的事情，两台服务器的运行环境是一样，唯一不同的是CloudCone是ubuntu，而瓦工是debian。CloudCone配置是4C4G的配置，按理说这样的配置怎么回复评论就卡了呢！
我也是的，有酷鸭数据香港的VPS，速度完美、性能超强，还去折腾什么CloudCone呀！不管了，等有时间再折腾了，我又把老张博客搬回酷鸭数据了！！有酷鸭数据这口精粮，那CloudCone那口粗糠就不吃了！
📢想要买酷鸭数据服务器的，走我的专属推广域名https://kooya.vip，有惊喜哟！