搬家上瘾

最后更新于 29 天前 60 次阅读


AI 摘要

搬家上瘾的经历让我频繁折腾自己的服务器。由于亲戚家地下室没有网络,我决定购买一个便宜的VPS,给网站换个高性能的“新家”。这次搬家步骤更加清晰,从1Panel管理到Docker安装WordPress,申请SSL证书,不开放外部端口,简化了操作。 在新服务器上,我学到了如何换语言环境,同时安装必要的软件和配置Nginx反向代理。虽然遇到一些小问题,比如用UI禁用端口访问和Nginx配置错误,但都及时解决了。我还使用了All in One WP Migration插件来搬家WordPress,虽然碰到上传大小限制,但通过修改服务器设置解决了问题。 最终,通过这种一系列的配置和调试,网站顺利迁移至新服务器,可以直接通过域名访问,心里总算踏实了不少。

只能说是隔一段时间不折磨一下自己就有点难受,白天上班,接住的亲戚地下室里有没有网没信号,但看到一个便宜vps还是没忍住立刻下单,给网站换个高性能新家

这次搬家的思路很清晰,1panel管理->docker安装wordpress->let's encrypt管理证书->不开放外部端口直接用nginx写好反代

服务器换成了netcup.ccp的rs1000,量大管饱,不过这个域名还真是第一次见,发邮件告诉我要登陆ccp也是愣了一下。是个德国服务商,我选了美东的一个服务器地址,开机一看竟然还是德语的,所以这次搬家第一个学到的小知识:

  • 给服务器换语言
    检查当前语言环境,选择安装语言包,生成英文环境然后重启服务器
locale
sudo apt-get update
sudo apt-get install locales
sudo update-locale LANG=en_US.UTF-8
sudo reboot

然后装装必需品,1panel:在线安装 - 1Panel 文档 从centos7开始安装1Panel - 紫罗兰Blog
nginx:下载链接

再之后可以直接软件商店安装数据库和Wordpress,默认使用docker安装的,挺好管理的,可以直接默认不对外开放端口不用以后再关了

  • 之后编写nginx以及申请ssl(提前把域名指过来
    首先安装nginx,编写nginx配置
# sudo nano /etc/nginx/sites-available/blog.sineeeee.life.conf
# HTTP → HTTPS 重定向
server {
    listen 80;
    server_name blog.sineeeee.life;
    return 301 https://hostrequest_uri;
}
# HTTPS 主配置
server {
   listen 443 ssl http2;
   server_name blog.sineeeee.life;

   ssl_certificate        /etc/letsencrypt/live/blog.sineeeee.life/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/blog.sineeeee.life/privkey.pem;

   location / {
       proxy_pass       http://127.0.0.1:8080;
       proxy_set_header Host            $host;
       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;
   }
}

然后连接到enable文件夹

sudo ln -s /etc/nginx/sites-available/auto.sineeeee.life.conf /etc/nginx/sites-enabled/

但是现在语法是有问题的,此时

sudo nginx -t
sudo systemctl reload nginx

是会报错证书错误的,所以先暂停nginx服务,然后再用certbot申请证书

sudo certbot certonly --standalone -d auto.domain.name

之后再启动

sudo systemctl start nginx

现在已经配置好了证书,反向代理,应用,应该已经可以直接域名访问开始设置了

  • 哦忘说了,这之前我干了一个最傻逼的事情,用UI把端口号访问panel后台给禁用了,然后nginx写错了
    解决办法是,用ssl连接把端口转发到本地
ssh -L 9999:127.0.0.1:12345 root@123.24.34.25

可以用localhost:9999/安全入口来访问了
当然,如果正确设置nginx,就可以把panel的端口给关闭ip访问了,对了,要把所有非域名访问都返回错误,可以配置一下/etc/nginx/sites-available/default

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    return 444;
}
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    # 临时占位的证书,有一个就行,不会用到
    ssl_certificate     /etc/letsencrypt/live/blog.sineeeee.life/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.sineeeee.life/privkey.pem;
    
    return 444;
}
  • wordpress搬家
    又到了老生常谈的wordpress搬家问题,我这次尝试了一下all in one WP migration搬家插件,总体还挺好用的,全都能搬过来,之前遇到的FIFU转移后需要手动保存刷新每篇文章的封面图片也没遇到了
    当然遇到了几个小问题记录一下

首先allinone插件导出备份是免费的,但是导入时除了直接上传都要付费,但哪怕是我的小站点几乎没有多少本地图片都要300多M,这时候上传会遇到几个容量大小限制,解决方法如下

  1. 服务器限制,根据插件自己提供的连接:How to Increase Maximum Upload File Size in WordPress - ServMask Helpdesk
  • 编辑.htaccess
php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value memory_limit 256M
php_value max_execution_time 300
php_value max_input_time 300
  • 编辑wp-config.php
@ini_set( 'upload_max_filesize' , '128M' );
@ini_set( 'post_max_size', '128M');
@ini_set( 'memory_limit', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set( 'max_input_time', '300' );

upload_max_filesize – set this to a value > than your backup
post_max_size – set this to a value > than your backup
memory_limit – set this to a value > than your backup
max_execution_time – set this to 0 (infinite)
2. nginx有一个上传限制,要在对应站点的nginx https server规则中中加一行
bash client_max_body_size 512M;
然后再重启nginx,刷新后台,应该就解除了所有的上传限制,我搜到有的网站说插件自己还有个50M的限制要改一下他自己的php设置,但是我没看到说的那段代码,可能是被更新掉了吧,毕竟大家都随便改的东西限制了也没啥用

不过我忽略了一个事,之前的wordpress我完全交给hostinger来管理,登陆后台都是直接重定向的不用登录

然后,当我成功确认导入了所有的数据,后台直接上不去了,初始化的账号也登不上去了,只能说导入的很彻底不过也好办,解决办法也挺奇怪的,gpt告诉我的,也不用去数据库调用户信息啥的,直接后台进入Wordpress容器在目录里创建个插件
原文:最直接的办法就是在激活主题或 MU-Plugin 里临时写一段代码来新建一个管理员账号然后登录后台后再把这段代码删掉。示例如下:

docker ps
docker exec -it <wordpress-container-id> bash
cd /var/www/html/wp-content
mkdir -p mu-plugins
cd mu-plugins

编写文件create-admin.php

cat > create-admin.php << 'EOF'

/**
 * Plugin Name: Temporary Admin Creator
 * Description: Creates a one-off admin account and then self-deletes.
 */
add_action('init', function(){
    $user = 'tempadmin';
    $pass = 'TempP@ssw0rd';
    $email = 'youremail@example.com';
    if ( ! username_exists($user) && ! email_exists($email) ) {
        $uid = wp_create_user( $user, $pass, $email );
        $u = new WP_User($uid);
        $u->set_role('administrator');
    }
    // 删除自己,防止重复执行
    unlink( __FILE__ );
});
EOF

打开浏览器访问网站主页,3这段 MU-Plugin 会自动运行,创建一个用户名 tempadmin、密码 TempP@ssw0rd 的管理员,然后进去新建好用户之后可以删除文件夹不留垃圾

OK,比较优雅的完成了一次搬家,没在服务器里乱拉太多屎。

  • 接下来想部署一下n8n

这个纯是工作上用到的,觉得非常好的东西,可以做简单的0代码api后端,还可以接入大模型和MCP,而且整体上比较成熟稳定。

前期和部署wordpress的流程没有区别,先让域名能访问服务
但是立刻遇到了两个bug,以下介绍细节与解决办法

  1. webhook提供的url是127.0.0.1:5678/workflow/123这样的,显然不行啊,虽然我试了一下直接用域名是可以请求到的,但还是要解决
  2. 修改好环境变量之后右上角一直显示 have a connection issue or the server is down.n8n should reconnect automatically once the issue is resolved.而且也确实不能联网

解决思路:

  1. 第一个问题好办,进入docker修改配置就好,以下贴出我的
# ./.env 容器配置
CONTAINER_NAME="bablababa"
HOST_IP="127.0.0.1"
PANEL_APP_PORT_HTTP=5678
WEBHOOK_URL=https://auto.sineeeee.life
# ./docker-compose.yml
networks:
1panel-network:
external: true

services:  
n8n:   
    image: n8nio/n8n:1.95.2 
    container_name: ${CONTAINER_NAME}    
   restart: always    
   ports: 
       - "{HOST_IP}:{PANEL_APP_PORT_HTTP}:5678" 
   volumes:   
       - ./data:/home/node/.n8n  
   env_file:
       - .env
   environment: # 统一字典格式,最少要有 ↓
       WEBHOOK_URL: ${WEBHOOK_URL}
       N8N_HOST: your.domain.name
       N8N_PROTOCOL: https
       N8N_PORT: 5678
       N8N_PROXY_HOPS: "1" # 反向代理层数
       N8N_PUSH_BACKEND: websocket # 若仍有问题可暂改为 sse
  1. 这个问题我没完全搞清楚原理,应该就是这个应用对协议要求比较严格,算了不多说了以后来看的我或别人建议直接问gpt,总之要修改nginx配置
# /etc/nginx/sites-available/domain.sineeeee.life.conf
# HTTP → HTTPS 重定向
server {
    listen 80;
    server_name domain.sineeeee.life;
    return 301 https://$host$request_uri;
}
# HTTPS 主配置
server {
    listen 443 ssl http2;
    server_name domain.sineeeee.life;

    client_max_body_size 512M;

    ssl_certificate     /etc/letsencrypt/live/domain.sineeeee.life/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.sineeeee.life/privkey.pem;

    location / {
        proxy_pass       http://127.0.0.1:5678;
        proxy_set_header Host              $host;
        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 Origin https://domain.sineeeee.life;
        # 支持 WebSocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

    }
}

就这个问题的解决,我折腾了一晚上到三点,issue和全网回答快翻了一遍了就是无法connect,最后第二天起床发现配置规则有两行写错位置了,光速修复

另外,我给公司服务器也配置了一下,大差不差,就是我用的是1panel自带的图形化OpenResty来管理网站和nginx规则,差别就是这个也是docker部署的,就有些本地路径的问题,唉算了我不想继续编辑了,直接截图吧

结果这还没解决,第二天实际使用的时候发现公司服务器现在的设置,竟然不能发请求?仔细看一下,curl的返回、ssl测试网站的信息,都提示中间证书不完整,去服务器配置看一下,openresty的配置竟然直接写着两行证书的位置:ssl_certificate /www/sites/domain,但是显然,我们的证书是在根目录etc/letsencrypt/live这里的,填写在这里因为容器访问不了外部所以会报错,而不报错的路径里根本就是空的
那解决也好解决,我把证书复制一份过来就行了(记得复制真实文件,live文件夹里的是连接过去的),但是我现在也没问gpt问明白为什么我所有项目都是这么配置的,那为啥浏览器上https能完全正常的访问,虽然是提示中间证书不完整,但是他妈这里面根本没证书啊怎么通过的
问题肯定和docker有点关系,哪里能看到我的真实证书哪里有不能了,但总之我没搞懂

就这样了,这次搬家虽然时间也不短,但是算是比较干净的一次,最开始建立博客的时候都是找最傻瓜的建站教程一点一点来,有什么问题就对着不同的博文一通乱弄,总归也算是搞好了,而这一次也算是我第一次认真做反代,研究nginx都什么功能,还是比较满意的,各种服务都把可维护性做好,对的起四核8g的大豪斯(反复强调)