不过，按理说，路由模式下，你的路由应该是独立的子网，也就是，对于光猫来说
你的路由固定成 192.168.1.3
对你通过路由连接的设备来说，子网固定在 192.168.50.1 这个网段是可行的，你可以在路由上找找配置
路由模式下
光猫的 LAN 口 和 路由的 WAN 口连接，对于光猫来说，你的路由是 192.168.168.1.3
你自己的设备与 路由 LAN 口或者 wifi 连接，走路由的 DHCP 走的是 192.168.50.1 这个网段
如果不是这样，可能你的路由与光猫是桥接或者中继，设备都在 192.168.1.x 这个网段下
如果只是想上网，那就把你的路由器固定，然后路由的 DHCP 分配中排除这个 ip
关掉路由的 DHCP ，光猫应该会给你通过路由接入的设备分配地址

核心还是你想做什么，自如的话应该有自带的路由器，这种情况下，不适合去关光猫的 DHCP 配置，你可以尝试把自己的路由 ip 固定成 192.168.1.3 ，然后设置光猫 DHCP 分配池子 比如起始地址从 192.168.1.10 开始，看这配置我估计 192.168.1.2 是自如自带的路由器

可以打开下思路，从上海出发，去苏州或者杭州玩个一两天

简单来说，图稳就考公，真的喜欢计算机就转码，各有利弊
1 、考公或者类似的路径，基本一眼望到头（普通人的情况），如果有变化对个人来说很难有什么应对手段（参考 99 年大下岗），但一般为了稳定也会有个善后，见仁见智
2 、转码，相对第一种会累的多（所以需要真喜欢），虽然自己有一些掌控感了，对应的也会不稳定（权责对等），同时客观的看，一定年纪后，中年危机如影随形（普通人的情况）
3 、你的本专业，我估计你比大多数人都更了解你的专业的情况，这方面业外人士恐怕很难建议

通常来说，你可能会想着，先走一个走不通再走另一个的想法，不是不行，但最好给自己设定个最后的界线，转行穷三年，到三十来岁还东一榔头西一棒锤的话，后面的确很难说，刚毕业的时候，你还有最大的资本“年轻”，当没了这个以后，不管走哪条路都得思考下核心竞争力是啥，反过来也一样，现在不管走哪条路你都有一个资本“年轻”

@GiftedJarvis 一般用户的密码在光猫背面（有个贴纸介绍登陆界面和密码的），账号一般是 useradmin 之类的，这一层一般能看到 DHCP 之类的配置信息，网络连通情况诸如此类的，管理员密码一般得找装宽带的师傅要（不一定给，也可以把光猫型号记下来网上找找有没有漏洞，有一些会有可以把整个配置导出来的接口，可以把管理员密码导出来），这个一般用来改桥接

做 NAS 还是算了吧，树莓派的读写都挺捉急的...搞集群倒不是不行但是 ARM...树莓派跑些定时任务小爬虫，或者连些摄像头传感器，玩具小车，单臂路由，家用智能设备的网关，之类的倒是挺合适，其它感觉不太行

估计光猫开 DHCP 了吧，路由器连上去，会被分配到光猫配置的 ip 上去，不连的时候就是默认配置了

只考虑两个问题
1 、明显，如果服务器端解析，如果服务器性能不行会有延迟（并发情况下会明显不过一般遇不到），客户端解析，则是看客户端性能。
2 、如果你打算写一套内容系统，可能存数据库会好点（推荐 sqlite 主要好迁移），如果只是单纯的博客，写文件会好点，以后想从动态改静态也可以直接用。

核心，还是你想用 php 实现什么功能，说到底无论是静态生成博客还是动态的 php 博客都有很多成熟的解决方案。
真的想折腾，静态资源上 CDN ，打开速度会快不少。

附上，我的博客 https://saltfish.vip/ 。
最开始使用的 Hexo 部署在 github Page 上。
后面自己用 Nodejs 进行了一些改造 ，买的服务器配置也和你的差不多，5mb 的带宽，不过我备案了。
其中也做了你现在想做的部分，编辑器,pjax ，文件预览，在线热更，预渲染，动态渲染（存数据库和文件也试过），live2d 之类的小插件。
然后服务器到期了，换了现在用的 Typecho ，部署在自己家里的迷你主机里，通过通道服务解析域名。
结论就是，如果只是想写博客，现成的方案会好一些。如果想顺便学点东西，什么想法都试下，会比较直观。

@Cesign
有时间我会关注一下..不过我对 Python 不是很熟悉，准备先进行研究。
话说，我刚看了一眼开发文档..
为什么不考虑在开发模式的镜像中直接挂载代码？
就是做镜像的时候不复制代码，做完时候把路径挂进去..
这样容器内代码是实时的，再配合 watchdog 就可以方便热更新了。
嘛，也是提升开发体验的小点，这块我可能可以先弄弄

@cesign
昨天装了个试了下，今天简单的看了下结构，的确是挺有意思的，我简单提提我的想法，你可以感受下有没有必要。
感觉上 kubespider 做了链接解析和调度。
下载部分虽是单独的模块，但为了便于使用和简单部署，实际最好是部署在同一台机子上。

有兴趣其实可以拆成两部分，解析的部分，也就是现在的“本体”，解析的结果不是直接去调下载模块，而是搞个消息队列（比如用 sqlite 模拟一个），下载模块通过消息队列与“本体”通信，根据类型去消费。
在这个模式下，下载模块可以不需要对外暴露端口（ pt 下载的另算）

单机模式下，这样的好处是便于控制，有的时候希望把下载的内容先加进去，晚些时候再下，也能比较容易的做下载记录的展示，可以减少暴露的端口（收缩关注的点）。

同时提供了多机的可能，本体可以做为注册中心，下载可以分在别的机子上，有需要的话也能做同步功能，增加应用场景。

坏处则是会增加不少复杂度，最后还是看有没有必要吧，这种架构层面的变更往往吃力不讨好。

现在在用 obsidian 学习成本其实不高，我之前也捣鼓过很多笔记软件，相对来说，更喜欢 obsidian

推荐，电子琴或者当钢琴弹，不怎么扰民，实在不行可以带耳机，而且打代码的情况下，手指一般都灵活
性质上可能和电吉他类似，但电吉他没有音箱的话效果差很多
尤克里里感觉..看风格吧
能做的事情，相对前两者会少些

看起来挺有意思的，先装起来试试。
看了下，解析和下载应该是分开的吧？
能否支持类似，先把解析的东西存起来，等下载的电脑开起来了，再推送下载类似这样的功能？
就是，解析，下载，以及 Jellyfin 之类的，不在同一台电脑下这样的场景？能否通过某种方式组织起来？

很难说有什么感想，建议 OP 换位思考，如果你是你父亲，你儿子这么想会是什么感受。
至于，房和车，货车耶，生产力工具，买房也可以看作，不想拖累子女，没直接找来要钱，其实已经不错了。

读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提供 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..