第一次拿到一台 Linux 服务器大多数人卡住的地方都差不多管理控制台里点了半天密码输了三遍终端上永远是一行 Connection timed out好不容易进去了apt install报一堆错装完 Python 又发现 pip 找不到装完 Node 又发现node -v是十几年前的老版本。这篇东西就是把这些坑一次说清楚——Linux 服务器登录、环境配置和日常使用从零开始纯小白视角但内容按照一个真在干活的人的思路来写。适合三类人看刚买完云服务器不知道怎么下手的、能登上去但环境总是配不干净的、以及配好了过两周自己都忘了当时怎么弄的人。我会把每一步为什么这么干讲透也会把那些官方文档从来不写、只有踩过才懂的经验单独拎出来说。1. 动手之前把服务器这件事先想明白1.1 云服务器交付给你的其实只有三样东西很多人买完服务器就急着登录结果连自己在连什么都没搞清楚。云服务器交付给你的核心就是三样一个可达的 IP或域名、一组登录凭据、一个系统镜像。剩下的所有东西——目录结构、软件、服务——都要你自己从零建起来。理解这一点很重要因为它决定了后面所有的操作逻辑这台机器是空白的你做的每一步配置都会留下痕迹也会留下隐患。那个 IP 可能是公网地址也可能是内网地址登录凭据可能是初始密码也可能是控制台帮你生成的一对密钥文件。系统镜像决定了你后面用apt还是dnf决定了配置文件放在/etc/nginx/sites-available还是/etc/nginx/conf.d这是新手最容易忽略的分水岭。现在不少云厂商默认提供国产发行版镜像比如基于 RPM 体系的 openEuler、Anolis 之类的包管理命令是dnf/yum跟你在网上看到的 Ubuntu 教程对不上照抄命令必然报错。所以第一步不是敲命令是确认发行版和版本号。提示登录成功后第一件事永远是执行cat /etc/os-release把 NAME 和 VERSION_ID 记在你自己的笔记里。后面所有装环境的命令都以这个为准不要凭印象。至于服务器虚拟化这个词你不需要现在就懂。简单类比一下云厂商有一台很大的物理机用虚拟化技术把它切成很多份你租的是其中一份所以你会看到 CPU 核数、内存、磁盘都是切片过的也可以随时升级配置。集群则是多台机器通过网络协同工作那是后面的事单机阶段完全不用碰。1.2 配置和预算别一上来就买最贵的先说结论个人学习用途2 核 2G 内存、40G 系统盘的入门配置足够跑一年真正卡你的不是 CPU 而是内存和磁盘 I/O。我见过太多人一上手买 8 核 16G然后在上面装了个博客一年下来资源占用不到 5%。反之也见过有人贪便宜买 1 核 1G编译一次前端项目直接 OOM 卡死最后连 SSH 都登不上去只能走控制台的 VNC 救援。判断配置够不够看你要干什么使用场景建议配置说明学习命令、写脚本、跑小爬虫1 核 2G内存别低于 1G否则装个数据库就吃紧部署个人网站、博客、API 服务2 核 4G要同时跑 Nginx 应用 数据库4G 是舒适区编译型项目、前端构建、跑 CI4 核 8G 起编译吃 CPU 和内存磁盘建议选 SSD 类型跑容器、多个中间件4 核 8G 起磁盘至少 60G镜像很占空间价格上同配置不同厂商差异挺大而且新用户首年优惠和续费价往往是两套价格体系。我的经验是先买最低配按量或短周期试一个月把流程跑通了再决定要不要升配。因为新手阶段 90% 的时间花在搞明白怎么用而不是跑得够不够快。另外一定要看清流量包很多便宜机型是限流量的跑下载或视频类应用超流量会被限速这个坑非常常见。1.3 我在买机器前后一定会做的准备清单磨刀不误砍柴工这几件事花十分钟能省掉后面几小时的抓瞎。本地终端工具Windows 用系统自带的 PowerShell 就够或者用 Windows TerminalmacOS、Linux 直接开终端。新手不建议一上来就装各种图形化客户端先把命令敲熟后面用工具才不会被工具牵着走。一个密码管理器或加密笔记服务器 IP、端口、用户名、密钥文件路径必须记下来。我见过太多人密钥文件随手扔在下载目录清理磁盘时删掉服务器直接失联。确认控制台的救援入口在哪每家的叫法不一样有的叫远程连接有的叫VNC 登录有的叫救援模式。先找到它再动手改 SSH 配置这是保命的东西。本地生成密钥对的时间密钥登录比密码登录安全得多而且省掉每次输密码。这一步可以在登录之前就做掉下面会讲具体命令。还有个小细节如果你用的是公司或学校的网络某些端口可能会被限制。这不代表服务器有问题换一个网络环境测一下就能区分开。排查问题的第一原则永远是先分清是本地问题还是远端问题后面第 6 节我会给一套完整的判断方法。2. 登录从控制台远程连接到 SSH 的完整路径2.1 三种登录方式各自适合什么场景登录方式没有绝对的好坏只有合不合适。第一种是控制台的网页远程连接厂商在管理后台提供的一个网页终端。优点是永远能进去即使你把 SSH 配置改崩了、防火墙把自己封了它还能救你。缺点是难用复制粘贴费劲断线就重连不能传文件。它的定位是消防通道平时不用出事的时候靠它。第二种是密码登录最直观输入 IP、用户名、密码就进去了。缺点是暴力破解攻击天天都在扫你的 22 端口日志里全是失败记录而且密码强度一旦不够被撞开只是时间问题。短期测试无所谓长期运行的机器我强烈建议关掉它。第三种是密钥登录用一对密钥代替密码分成私钥和公钥。公钥放在服务器上私钥留在你自己电脑里登录时两边做一次数学验证。私钥不泄露别人就进不来而且免密日常用最舒服。这是生产环境的标配做法也是我推荐所有新手直接上手的方式。三种方式的关系不是替代而是叠加控制台保底密钥日常用密码登录在验证密钥能用之后关掉。2.2 密钥登录全流程从生成到免密成功先在你自己的电脑上生成密钥对。打开终端执行ssh-keygen -t ed25519 -C my-first-server中间会问你密钥保存路径直接回车用默认一般在~/.ssh/id_ed25519然后问你要不要设密码短语passphrase。这一步建议设一个相当于给私钥再加一把锁即使文件被拷走也用不了。如果嫌麻烦回车跳过也行但要清楚这是拿安全性换便利。执行完你会得到两个文件id_ed25519私钥绝对不能外传和id_ed25519.pub公钥可以随便给人。用cat ~/.ssh/id_ed25519.pub把公钥内容打印出来是一整行文字。接下来把这行公钥放到服务器的~/.ssh/authorized_keys文件里。有两种做法做法一先用密码登进去然后手动追加。登录之后执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 这里粘贴你刚才复制的公钥整行内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys做法二用 ssh-copy-id 一步到位ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名服务器IP它会让你输一次密码输完自动把公钥写好权限也顺手设对了。注意权限是密钥登录失败的头号原因没有之一。~/.ssh必须是 700authorized_keys必须是 600~家目录不能对同组或其他用户可写。SSH 服务端会因为权限过宽直接拒绝使用这个密钥而且它不会明确告诉你原因日志里只有一句轻描淡写的提示。公钥放好之后优化一下本地配置省得每次敲一长串。在本地~/.ssh/config里加一段Host myserver HostName 1.2.3.4 User deploy Port 22 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 60 ServerAliveCountMax 3以后再登录只需要敲ssh myserver。ServerAliveInterval那两行的作用是每隔 60 秒发一次心跳包防止长时间不操作被网络设备掐断连接——这个参数对经常挂着终端跑任务的人特别有用我几乎每台机器都加。验证免密登录成功之后再去关掉密码登录。编辑服务器的/etc/ssh/sshd_configPasswordAuthentication no PubkeyAuthentication yes PermitRootLogin no改完先别急着重启服务先执行sudo sshd -t检查配置语法。语法没问题再sudo systemctl reload sshd部分发行版服务名是ssh。这里顺序极其重要先确认密钥能登录再关密码反过来的话你就只能去控制台求救了。2.3 登录失败排查把报错对号入座登录失败的信息其实很诚实只是新手看不懂。下面这张表基本能覆盖九成情况报错信息大概率原因处理方向Connection timed out网络不通、IP 错、安全组未放行确认 IP检查云控制台安全组是否放行 22 端口Connection refused端口没开、服务没起、端口改了确认 sshd 是否运行确认端口号Permission denied (publickey)公钥没放对、权限过宽、用错了用户检查~/.ssh权限和 authorized_keys 内容Host key verification failed服务器重装过本地指纹变了删掉本地~/.ssh/known_hosts里对应那行Permission denied (password)密码错、或已关闭密码登录用密钥登录或去控制台重置密码Too many authentication failures本地私钥太多逐个尝试被拒在 config 里指定 IdentityFile或加 IdentitiesOnly yes我自己的排查顺序是固定的先在本机ping一下 IP 通不通再telnet IP 22或nc -vz IP 22看端口通不通最后再怀疑账号和密钥。前两步不通问题一定在网络侧或云厂商的安全组跟你服务器里配了什么完全无关别浪费时间在服务器内部找原因。还有一个特别隐蔽的坑有些云厂商的默认安全组只放行了部分端口或者你换了 SSH 端口但忘了在安全组里同步放行结果就是把自己关在门外。改端口之前务必先在安全组里把新端口加上再改服务配置顺序错了就得走控制台的救援通道了。3. 登录成功后的前 30 分钟把地基打牢3.1 系统更新、时区与时间同步刚拿到的机器系统包基本都是几个月甚至一两年前的先更新一轮# Debian / Ubuntu 系 sudo apt update sudo apt upgrade -y # RHEL / CentOS / 国产 RPM 系 sudo dnf update -y更新完之后时区这件事必须马上处理。默认时区多半是 UTC你在本地写日志、看定时任务、排查故障的时候时间对不上会非常折磨人。一条命令搞定sudo timedatectl set-timezone Asia/Shanghai timedatectl status时区对了还要保证时间本身是准的。服务器时间漂移会引发一堆玄学问题HTTPS 证书校验失败、数据库主从复制报错、定时任务提前或延后执行、日志时间戳乱序。现代发行版一般自带时间同步服务先确认它是不是开着的timedatectl set-ntp true systemctl status systemd-timesyncd如果是用 chrony 的发行版检查方式和配置位置不一样sudo systemctl enable --now chronyd chronyc sources -v输出里每行前面有个符号^*表示当前正在使用的同步源能看到它就说明同步正常。提示如果在云上优先用云厂商控制台里公布的内网时间服务器地址延迟低而且不占公网流量。没有的话用公开的 NTP 池服务也可以配置写在 chrony.conf 里加一行server 地址 iburst就够了改完systemctl restart chronyd。3.2 新建用户与权限管理别一直用 root日常操作一直用 root 是新手最危险的习惯。一条敲错的rm -rf在 root 手里是不可逆的在普通用户手里顶多报个权限不足。所以第二步就是建一个自己的账号# Debian / Ubuntu sudo adduser deploy sudo usermod -aG sudo deploy # RHEL / CentOS 系 sudo useradd -m -s /bin/bash deploy sudo passwd deploy sudo usermod -aG wheel deploy这里有个容易混的点Ubuntu 系把有 sudo 权限的用户加进sudo组RHEL 系是加进wheel组。加错组的话新用户执行 sudo 会提示不在 sudoers 文件里别以为是系统坏了。建好之后用新账号登录一次跑个sudo whoami输出root就说明提权正常。确认没问题再去 sshd 配置里把PermitRootLogin改成no。权限体系这块再补两条实用经验。一是团队协作时优先用用户组管权限比如把几个人加进同一个组把项目目录的属组改成这个组然后chmod 2775让新文件自动继承属组比一个个chown高效得多。二是别随便chmod 777这是新手最爱的万能药但等于把门拆了。文件权限报错的时候正确的问法是这个进程以哪个用户身份运行它需要读还是写而不是一把梭 777 算了。3.3 安全基线三件套按顺序做公网上的服务器从开机那一刻起就在被扫。安全配置不需要多复杂把下面三件事做完就能挡掉绝大部分自动化攻击。第一件收紧 SSH。除了上面说的关密码登录、禁 root 直连还可以把默认的 22 端口改掉。这不是隐匿安全纯粹是为了把日志里的噪音降下来——改成非标端口之后扫描量能少九成以上。改端口记得同步改云安全组。第二件开防火墙只放必要的端口。Ubuntu 系用 ufwsudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status verboseRHEL 系用 firewalldsudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload开启防火墙之前一定要先把 SSH 端口规则加进去顺序反了就是自己把自己锁在外面然后老老实实走控制台救援。第三件装个登录防护工具。类似 fail2ban 这类工具的原理很简单盯着日志里连续登录失败的来源 IP超过阈值就临时封掉。配置成本很低收益很直接尤其是你还开着密码登录的时候。sudo apt install fail2ban -y sudo systemctl enable --now fail2ban sudo fail2ban-client status sshd最后一条经验也是我最想强调的云控制台的安全组是外层系统防火墙是内层两层都要放行端口才行。很多人只配了系统防火墙结果外网死活访问不了排查半天才发现是安全组里没开——这两个地方是独立的谁也不会自动同步谁。4. 环境配置不同技术栈的安装取舍4.1 先把编译工具链装好能省一半麻烦不管你后面要装 Python 还是 Node只要涉及源码编译就会用到 gcc、make 这些。新手最常见的装不上其实不是软件的问题是缺编译依赖。# Debian / Ubuntu sudo apt install -y build-essential git curl wget vim unzip # RHEL / CentOS 系 sudo dnf groupinstall -y Development Tools sudo dnf install -y git curl wget vim unzipbuild-essential这个包名很形象它就是基础设施gcc、g、make、libc 开发头文件一整套。装上它后面遇到command gcc not found或者Python.h: No such file or directory这类报错的概率会大幅下降。关于软件源还有两点值得说。一是换国内镜像源能显著提速无论 apt、dnf 还是 pip、npm原理都一样——把官方源地址换成地理位置更近的镜像站地址。具体地址以镜像站官网公布为准改之前记得备份原配置文件改完更新一次索引验证。二是千万不要乱加第三方源。新手看到教程里加了某个源就照抄结果源之间互相冲突后面apt upgrade直接依赖爆炸。加源的原则是只加你确实需要、且官方文档明确要求的。4.2 Python 环境系统 Python 和你自己的 Python 要分开系统自带的 Python 是给系统工具用的不要去动它不要用它装项目依赖。很多 Linux 发行版的包管理工具本身就是 Python 写的你把它依赖搞乱了系统会出各种奇怪问题。正确做法是用虚拟环境隔离sudo apt install -y python3 python3-pip python3-venv python3 -m venv ~/venvs/demo source ~/venvs/demo/bin/activate pip install requests激活之后命令行前面会出现(demo)前缀这时候pip install装的东西只在这个环境里退出用deactivate。这个习惯一定要在第一天就养成等项目依赖冲突了再回头改成本高得多。如果涉及深度学习和科学计算conda 系列会更省事因为它能连 C 库一起管。我的建议是普通 Web 项目用 venv 就够轻量、干净、不污染系统需要 CUDA、特定版本 NumPy 这类复杂依赖的场景再用 conda。两者别在同一台机器上混着乱用容易把 PATH 搞乱which python查半天查不出来是谁。注意如果pip install报externally-managed-environment之类的错误说明系统禁止直接往全局环境装包。这不是故障是保护机制用虚拟环境就能绕过别去用--break-system-packages强拆。4.3 Node.js版本管理比安装本身更重要Node 的坑不在于装不上而在于版本太多、切换太频繁。今天这个项目要 16明天那个要 20直接用系统源装的版本往往又老又固定。所以正确姿势是用版本管理工具# 方式一nvm管理多版本最方便 # 按官方文档安装 nvm然后在 shell 配置里加载 nvm install 20 nvm use 20 nvm alias default 20# 方式二官方二进制包适合不想引入额外工具的场景 wget https://nodejs.org/dist/v20.x.x/node-v20.x.x-linux-x64.tar.xz sudo tar -xJf node-v20.x.x-linux-x64.tar.xz -C /opt sudo ln -s /opt/node-v20.x.x-linux-x64/bin/node /usr/local/bin/node sudo ln -s /opt/node-v20.x.x-linux-x64/bin/npm /usr/local/bin/npm二进制包这种方式的好处是干净可控缺点是升级要手动做一遍。nvm 的好处是nvm use一条命令切版本缺点是它在非交互式 shell 里默认不加载——这是个大坑很多人发现手动敲 node 没问题一放到定时任务或 systemd 服务里就报node: command not found根源就在这。解决办法是在脚本里显式声明 PATH或者干脆用绝对路径。npm 也建议换镜像源否则装依赖能等到怀疑人生npm config set registry 镜像源地址再加一条npm 全局装包不要用 sudo。用 sudo 装会把文件属主变成 root后面升级和卸载都会因为权限问题报错而且新手根本想不到是这个原因。4.4 Java、Maven 与 C/C 工具链的配置要点Java 这边直接装发行版提供的 JDK 是最稳的sudo apt install -y openjdk-17-jdk java -version如果机器上要同时存在多个 JDK 版本用update-alternatives管理切换sudo update-alternatives --config javaMaven 的安装很简单解压后配好PATH就行。真正影响体验的是settings.xml里的镜像配置——默认中央仓库在国内访问速度很一般换成公开镜像站会快很多。配置写在mirrors节点里指定一个mirrorOfcentral/mirrorOf的镜像即可。C/C 相对省心build-essential装完 gcc/g 就有了再补上 cmake 和调试器sudo apt install -y cmake gdb这里有个新手高频困惑gcc能编译但不能直接跑因为编译产物默认叫a.out得用./a.out执行。加上-o参数可以指定输出名gcc main.c -o main然后./main。理解了编译和执行是两个动作就不会再问为什么没反应了。要在本地编辑器里做 C/C 开发配置的核心是三样编译器路径、头文件搜索路径、调试器路径。这三样在服务器上通常是标准位置配置的时候只要填对绝对路径就行。如果你用的是远程开发的模式本地不需要装编译器配置指向远端环境即可这个在第 5 节展开。4.5 用容器把环境锁起来如果要跑数据库、消息队列、缓存这类中间件我强烈建议用容器而不是直接装在系统里sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker sudo usermod -aG docker $USER加完组之后一定要退出登录再进一次否则组权限不生效你会一直看到permission denied连接 docker 守护进程的报错。这个坑几乎每个人都踩过一次。容器的价值在于三件事环境可复现、卸载干净、不污染宿主机。用 apt 装的数据库版本升级和卸载都是麻烦事用容器一个docker compose down加删掉数据卷就彻底干净了。写个docker-compose.yml把端口映射、数据卷、环境变量都固定下来换台机器一样能跑起来这才是环境配置的终极形态。配置方式适合场景主要风险系统包管理器直接装常用工具、编译工具链版本受限升级影响面大虚拟环境 / 版本管理工具语言运行时、项目依赖PATH 配置容易出错容器中间件、数据库、多版本并存磁盘占用、数据卷管理要上心5. 远程开发让本地编辑器和服务器连起来5.1 远程开发环境的配置全过程在服务器上用 vim 改代码短期可以长期效率太低。正确做法是让本地的图形化编辑器直接操作服务器上的文件代码存在服务器上编辑体验在本地。这类功能在不同编辑器里叫法不同原理都一样本地客户端通过 SSH 连上服务器在服务器端启动一个轻量服务然后本地界面和远端文件系统打通。配置流程大致是三步。第一步确保本地已经能免密 SSH 登录也就是第 2 节配好的那套。远程开发工具一般直接复用~/.ssh/config所以你在那里配好的 Host 别名可以直接被识别到。第二步在编辑器里安装远程开发插件选择连接到目标主机。首次连接会自动在服务器上部署服务端组件需要几十秒到一两分钟取决于网络。这个过程失败的话看输出面板里的日志通常是服务器磁盘满、或者/tmp无写权限。第三步连上之后打开远端目录按需安装扩展。这里有个关键认知扩展是分本地和远端两份的。语法高亮、语言服务、调试器这类需要读代码的插件必须装到远端主题、快捷键这类装本地就行。很多人报告插件装了没生效就是装错位置了。用这套方式的额外好处是终端也一起打通了。你在编辑器里开的终端就是服务器上的 shell跑构建、跑测试都不用切窗口端口转发也会自动处理——比如你的服务监听 3000 端口编辑器会把它映射到本地浏览器直接开 localhost 就能访问不用去改防火墙。5.2 中文乱码、换行符和文件解压乱码这三个问题看起来分散本质是同一件事编码不一致。先说终端里的中文乱码。排查顺序是先locale看当前环境变量的值如果LANG是POSIX或者带.ISO-8859-1之类基本就是它的问题。设置成 UTF-8sudo locale-gen zh_CN.UTF-8 sudo update-locale LANGzh_CN.UTF-8执行完退出重新登录。如果locale显示zh_CN.UTF-8还是乱码那就是终端软件的字符集设置问题检查一下本地终端是不是 UTF-8。再说解压乱码。这是最典型的一个坑Windows 上用压缩软件打的包文件名通常按 GBK 编码存储Linux 下 unzip 默认按 UTF-8 解释结果就是一串问号或者方块。解决办法有好几种我最常用的是换工具sudo apt install -y unar unar yourfile.zipunar会自动识别编码省心。如果坚持用 unzip新版支持指定编码unzip -O gbk yourfile.zip不同发行版编译选项不一样-O参数不一定支持报错的话就用 unar 或者7z x。最后说换行符。Windows 文本文件的行尾是\r\nLinux 是\n。带着\r的 shell 脚本在 Linux 上跑会报一些很诡异的错误比如$\r: command not found或者参数末尾莫名其妙多个字符。转换一条命令sudo apt install -y dos2unix dos2unix script.sh提示如果你是从 Windows 上传脚本到服务器养成习惯上传后先dos2unix一遍再执行能省掉大量莫名其妙的报错。5.3 端口转发与本地调试服务器上的服务往往只监听127.0.0.1从外面直接访问不到。有几种打通方式。最省事的是编辑器自带的自动转发识别到服务监听的端口后自动映射到本地用来做开发调试非常方便。通用做法是 SSH 本地端口转发一条命令把服务器的端口拉到本地ssh -L 8080:127.0.0.1:80 myserver意思是本地访问localhost:8080的流量通过 SSH 隧道转发到服务器的127.0.0.1:80。这条命令在排查服务到底起没起的时候特别好用——如果本地 8080 能通说明服务本身没问题问题在防火墙或者反向代理配置上如果本地也不通那就是服务本身没跑起来。这个二分法能帮你快速定位问题在应用层还是网络层。如果是正式对外提供服务那就不是端口转发的事了需要正经的配置应用监听端口、反向代理比如 Nginx转发、防火墙放行、域名解析。这几步的检查顺序我建议固定为应用本机curl 127.0.0.1:端口能不能通 → 服务器内网 IP 能不能通 → 公网 IP:端口能不能通 → 域名能不能通。一层一层往外扩哪一层断掉问题就在哪一层别跳步骤。6. 常用命令与排障我的肌肉记忆清单6.1 四类高频命令覆盖日常八成操作命令这东西背手册没用按场景记才记得住。我把最常用的按用途分成四类。文件和目录命令用途常用参数ls列目录-lh看大小、-a含隐藏文件cd / pwd切换 / 显示当前路径cd -回上一个目录cp / mv / rm复制 / 移动 / 删除rm -i删前确认别乱用-rffind按条件找文件find . -name *.log -mtime 7du / df目录占用 / 磁盘剩余du -sh *、df -htail看文件末尾tail -f实时跟踪日志grep文本搜索grep -rn 关键词 .递归带行号进程和资源ps aux | grep 关键词 # 找进程 top # 实时看资源按 M 按内存排序 kill -9 PID # 强杀先试普通 kill 再上 -9 free -h # 内存使用 uptime # 负载和运行时长磁盘和网络df -h # 磁盘整体使用率 du -sh /var/* | sort -h # 找出哪个目录最占空间 ss -tunlp # 看端口监听情况 curl -I 地址 # 只看响应头排查服务是否响应服务管理systemctl status 服务名 # 看状态 systemctl restart 服务名 # 重启 systemctl enable 服务名 # 设开机自启 journalctl -u 服务名 -f # 跟踪该服务的日志ss -tunlp这条命令我几乎每小时都会用一次。-t是 TCP-u是 UDP-n不做域名解析快-l只看监听状态-p显示进程。服务起了但访问不了的场景先跑它看端口到底有没有在监听、监听在哪张网卡上。如果显示的是127.0.0.1:8080那外网访问不了是必然的得改配置让它监听0.0.0.0。6.2 日志排查三板斧服务出问题答案一定在日志里只是看的人多、会看的人少。我总结成三板斧。第一板斧实时跟踪。tail -f 日志文件挂在那里然后去复现问题出错的瞬间就能看到。比事后翻文件高效得多。第二板斧按时间窗口过滤。日志文件几百兆的时候直接打开是没有意义的。用时间范围圈出来journalctl -u myapp --since 10 min ago journalctl -u myapp --since 2024-01-01 10:00 --until 2024-01-01 10:30第三板斧找上下文。定位到报错那一行之后一定要往下多看 20 行。真正的根因往往在那一行的下面前面那句只是第一个被触发的异常。再加上一条经验看日志之前先确认服务时间对不对。如果服务器时区是 UTC你按本地时间去过滤会一条都查不到然后开始怀疑人生。这就是第 3 节强调时区的原因。6.3 常见问题速查表症状常见原因解决方向No space left on device磁盘满通常是日志df -h找分区du -sh找目录清理或轮转日志command not foundPATH 没配、软件没装which确认检查 PATH用绝对路径Permission denied文件权限或属主不对看进程属主调 chmod/chown别直接 777Address already in use端口被占ss -tunlp找占用进程杀掉或换端口服务启动即退出配置错、依赖缺失systemctl status看退出码journalctl看详情外部访问不通本机可通防火墙或安全组逐层检查系统防火墙和云安全组ssh 突然连不上改配置或防火墙误封走控制台远程连接救援上传文件后脚本报错Windows 换行符dos2unix转换中文全是乱码locale 未设 UTF-8检查locale生成并设置 UTF-8定时任务不生效环境变量缺失脚本里写绝对路径手动跑一遍验证这张表我建议存下来出问题的时候从上往下扫一遍比漫无目的搜索快得多。7. 我自己的几条长期习惯写到这儿把前面散落的经验收一收说几条我坚持了很多年的习惯。第一条每台新机器都写一个初始化脚本。内容就是把本文第 3、4 节的命令按顺序串起来更新系统、设时区、装基础工具、建用户、配防火墙。新机器上来跑一次十分钟搞定而且不会漏步骤。脚本我会存在自己的代码仓库里随着踩坑不断补充。第二条任何改配置的动作都先备份。改/etc/ssh/sshd_config之前先cp sshd_config sshd_config.bak改完先验证语法再 reload。备份的成本是两秒钟不备份的成本可能是一小时。第三条改远程访问相关的配置永远保持一个已经连着的 SSH 会话不动。在另一个窗口改配置、重启服务如果新窗口连不上老窗口还能救你。这个习惯救过我至少五次。第四条给自己留一份恢复笔记。记录这台机器的 IP、SSH 端口、用户名、密钥路径、装了哪些服务、数据存在哪个目录、备份怎么恢复。我遇到过太多次三个月前配的东西现在完全想不起来当时怎么弄的笔记比记忆可靠得多。第五条也是最重要的一条理解每一步在做什么而不是复制粘贴。网上教程的版本、路径、包名都可能和你的环境不一样照抄必然有翻车的时候。你不需要记住所有命令但要知道每一条命令解决了什么问题——这样报错的时候你才知道该往哪个方向查。这套流程我用了很多年从最便宜的单核机器到后面配了多台机器的环境底层逻辑一直没变先能进去再打地基然后按需装环境最后把日常操作变成肌肉记忆。卡住的时候别急回到本地问题还是远端问题网络层还是应用层这两个二分法绝大多数故障都能自己定位出来。