2026-05-20 03:12:04
本文将指导如何升级 Ubuntu 24.04 Noble Numbat 到 Ubuntu 26.04 Resolute Raccoon。
相关教程：Ubuntu 22.04 Jammy 升级 Ubuntu 24.04 Noble。
除非你是物理服务器，以及没有用过奇奇怪怪定制或修改的内核的 KVM 构架的 VPS 和云主机，否则升级大版本更新内核是有一定机率导致 Grub 加载失败的，切记备份重要数据！
OpenVZ 和 LXC 构架的 VPS 是无法升级的，因为他们没有自己独立的内核
再强调一遍，一定要备份重要数据！
Ubuntu 26.04 LTS 已经正式发布，不过 Ubuntu LTS 版本的自动升级提示通常会等到第一个小版本发布后才会开放。如果你在 Ubuntu 26.04.1 LTS 发布前从 Ubuntu 24.04 LTS 升级，do-release-upgrade 需要加上 -d 参数。
以下操作需要在 root 用户下完成，请使用 sudo -i 或 su root 切换到 root 用户进行操作
首先需要更新你当前的系统
apt update
apt upgrade -y
apt dist-upgrade -y
apt autoclean
apt autoremove -y
如果内核更新了，可以重启让最新的内核生效，也可以直接进行升级。
这里有两种升级系统的方法，第一种是使用 do-release-upgrade 命令，第二种是手动更新 apt 源文件。
do-release-upgrade 命令首先需要安装 ubuntu-release-upgrader-core 包：
apt install ubuntu-release-upgrader-core
然后修改 /etc/update-manager/release-upgrades 文件，确保 Prompt 值为 lts：
cat /etc/update-manager/release-upgrades | grep lts
显示如下内容即可：
root@ubuntu ~ # cat /etc/update-manager/release-upgrades | grep lts
# lts - Check to see if a new LTS release is available. The upgrader
Prompt=lts
最后执行以下命令升级系统：
do-release-upgrade -d
等 Ubuntu 26.04.1 LTS 发布并开放 LTS 自动升级后，可以直接使用：
do-release-upgrade
apt 源文件Ubuntu 24.04 的默认软件源配置文件已经变更为 DEB822 格式，路径为 /etc/apt/sources.list.d/ubuntu.sources。我们可以直接替换 noble 为 resolute：
sed -i 's/noble/resolute/g' /etc/apt/sources.list.d/ubuntu.sources
如果你的系统里仍然有传统 One-Line-Style 的源文件，也可以一并替换：
sed -i 's/noble/resolute/g' /etc/apt/sources.list
sed -i 's/noble/resolute/g' /etc/apt/sources.list.d/*.list
如果没有对应文件会提示诸如 sed: can't read /etc/apt/sources.list: No such file or directory 的错误，忽略即可。
或者直接一行命令：
sed -i 's/noble/resolute/g' /etc/apt/sources.list /etc/apt/sources.list.d/*.{list,sources} 2>/dev/null
使用 DEB822 格式的源文件 /etc/apt/sources.list.d/ubuntu.sources 应该是类似这样的：
Types: deb
URIs: https://archive.ubuntu.com/ubuntu
Suites: resolute resolute-updates resolute-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Types: deb
URIs: http://security.ubuntu.com/ubuntu
Suites: resolute-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
国内服务器可以替换 archive.ubuntu.com 和 security.ubuntu.com 为 mirrors.tuna.tsinghua.edu.cn
如果你有第三方源或 PPA，建议先备份并根据情况临时禁用，升级完成后再确认是否支持 Ubuntu 26.04：
mkdir -p /root/apt-sources-backup
cp -a /etc/apt/sources.list.d /root/apt-sources-backup/
第三方源通常需要单独检查，不能简单把 noble 替换成 resolute。
然后我们再次执行更新系统：
apt update
apt upgrade -y
apt full-upgrade -y
更新过程中会提示一些软件是否需要自动重启，选 Yes 即可，以及一些软件的配置文件是否需要更新，按照自己的情况选择即可，默认回车即视为使用旧的配置文件，一般会出现在 OpenSSH 等软件的更新上。
更新后删除不必要的软件和依赖：
apt autoclean
apt autoremove -y
然后我们使用 reboot 命令重启系统，耐心等待后，查看最新的系统版本：
root@ubuntu ~ # lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 26.04 LTS
Release: 26.04
Codename: resolute
root@ubuntu ~ # uname -a
Linux Nana 7.0.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026 x86_64 GNU/Linux
这时我们就已经更新到了最新的 Ubuntu 26.04 Resolute 和内核了。
2026-01-21 12:53:46
本文介绍在 WSL 2 中使用 Docker 的桥接模式（bridge network）访问 HTTPS 时出现超时问题的解决方法。
最近一直在 Windows 下使用基于 WSL 2 的 Debian 进行开发。许多场景下需要使用 Docker 构建镜像，但过程中遇到一个奇怪的问题，在 Docker 容器内部访问 HTTP 站点时一切正常：
$ docker run --rm curlimages/curl time curl -s http://ip.gs
192.0.2.2
real 0m 0.02s
user 0m 0.00s
sys 0m 0.00s
一旦切换为 HTTPS，访问就会明显变慢，并且有一定概率出现超时：
$ docker run --rm curlimages/curl time curl -s https://ip.gs
192.0.2.2
real 0m 6.52s
user 0m 0.00s
sys 0m 0.00s
然而，如果将 Docker 切换到 Host 模式（--network=host），访问又恢复正常：
$ docker run --rm --network=host curlimages/curl time curl -s https://ip.gs
192.2.0.2
real 0m 0.28s
user 0m 0.00s
sys 0m 0.00s
在排查了 WSL 2 的 Debian 系统配置后，最终请教 ChatGPT 得到结论：
Path MTU 与防火墙流量检查（inspection）不兼容导致问题
解决方法很简单：将 WSL 2 虚拟网络的 MTU 下调为 1400 即可。
在 WSL 2 的系统里，使用 root 用户修改 /etc/docker/daemon.json 文件：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "3"
},
"mtu": 1400,
"dns": [
"8.8.8.8",
"1.1.1.1"
]
}
其中 "mtu": 1400, 是关键配置。
然后在 Windows 下把 WSL 2 关闭：
wsl --shutdown
在 Windows 下使用管理员身份运行 Powershell，检查网卡名称：
PS C:\Users\showfom> Get-NetAdapter | Where-Object { $_.Name -like "*WSL*" }
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
vEthernet (WSL (Hyper-V … Hyper-V Virtual Ethernet Adapter #3 41 Up 12-34-56-78-AB-CD 10 Gbps
PS C:\Users\showfom> Get-NetAdapter | Format-Table -AutoSize
Name InterfaceDescription ifIndex Status MacAddress Lin
kSp
eed
---- -------------------- ------- ------ ---------- ---
vEthernet (Default Switch) Hyper-V Virtual Ethernet Adapter 35 Up 12-34-56-78-AB-AB …ps
vEthernet (WSL (Hyper-V firewall)) Hyper-V Virtual Ethernet Adapter #3 41 Up 12-34-56-78-AB-CD …ps
输出可以看到完整名称为 vEthernet (WSL (Hyper-V firewall))，然后为其设置 MTU：
netsh interface ipv4 set subinterface "vEthernet (WSL (Hyper-V firewall))" mtu=1400 store=persistent
出现 Ok. 字样即代表设置成功。
然后重新运行 WSL 2 虚拟机：
wsl -d debian
再次测试：
$ docker run --rm curlimages/curl time curl -s https://ip.gs
192.0.2.2
real 0m 0.28s
user 0m 0.00s
sys 0m 0.00s
问题已完美解决，可以继续愉快地 Vibe Coding 了！ ★,°:.☆(￣▽￣)/$:.°★ 。
2026-01-16 11:05:21
本文将介绍在 Debian 或 Ubuntu 下使用 nginx-acme 自动签发并配置 SSL 证书的方法。
本文适合 Debian Stable 和 Ubuntu LTS，请使用 root 用户进行操作。
nginx-acme 是 Nginx 官方开发的基于 ACME 协议自动签发 SSL 证书的模块，隔壁 Caddy 都出了几百年的功能， Nginx 也终于赶上了。
和 Nginx 使用 C 语言开发不同，这个模块是用 Rust 语言开发的，这里就不做评价。
这个模块支持 RFC8555、RFC8737、RFC8738 和 draft-ietf-acme-profiles 等规范，目前我实际测试下来已经基本可以用于生产环境。
这里我们使用烧饼博客打包的 N.WTF，这个项目已经集成了 nginx-acme 模块，可以做到开箱即用。
首先，安装一些必要的软件包：
sudo apt update
sudo apt upgrade -y
sudo apt install curl vim wget gnupg dpkg apt-transport-https lsb-release ca-certificates
然后加入 N.WTF 的 GPG 公钥和 apt 源：
curl -sSL https://n.wtf/public.key | sudo bash -c 'gpg --dearmor > /usr/share/keyrings/n.wtf.gpg'
sudo bash -c 'echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/n.wtf.gpg] https://mirror-cdn.xtom.com/sb/nginx/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/n.wtf.list'
国内机器可以用清华 TUNA 的国内源：
curl -sSL https://mirrors.tuna.tsinghua.edu.cn/n.wtf/public.key | sudo bash -c 'gpg --dearmor > /usr/share/keyrings/n.wtf.gpg'
sudo bash -c 'echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/n.wtf.gpg] https://mirrors.tuna.tsinghua.edu.cn/n.wtf/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/n.wtf.list'
Debian 下也可以直接使用 extrepo:
sudo apt update
sudo apt install extrepo -y
sudo extrepo enable n.wtf
接着更新系统并安装 Nginx：
sudo apt update
sudo apt install nginx-extras -y
准备工作很简单，我们需要建立一个目录来存放 SSL 证书并给予正确的权限，这里我们以 /var/cache/nginx/letsencrypt 为演示：
sudo mkdir -p /var/cache/nginx
sudo mkdir -p /var/cache/nginx/letsencrypt
sudo chown 33:33 /var/cache/nginx -R
然后别忘了把域名解析到你的服务器哦！
我们以 example.com 为例，假设你的邮箱是 [email protected]，需要配置的域名是 example.com 和 www.example.com，并且希望访问 www.example.com 跳转到 example.com：
直接修改 /etc/nginx/sites-enabled/default 文件：
resolver 8.8.8.8:53 ipv6=off valid=5s;
acme_issuer letsencrypt {
uri https://acme-v02.api.letsencrypt.org/directory;
contact [email protected];
state_path /var/cache/nginx/letsencrypt;
accept_terms_of_service;
ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
ssl_verify off;
}
acme_shared_zone zone=ngx_acme_shared:1M;
server {
# Listen on port 80 for all IPv4 and IPv6 addresses
listen 80 default_server;
listen [::]:80 default_server;
# Match all domain names
server_name _;
location /.well-known/ {
return 404;
}
location / {
# Redirect all other HTTP requests to HTTPS using 301 permanent redirect
return 301 https://$host$request_uri;
}
}
server {
# Standard TLS listening
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
# HTTP/2 protocol support
http2 on;
# HTTP/3 QUIC protocol support
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
add_header X-Protocol $server_protocol always;
server_name example.com;
root /var/www/html;
index index.html;
# modern configuration
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_prefer_server_ciphers off;
acme_certificate letsencrypt;
ssl_certificate $acme_certificate;
ssl_certificate_key $acme_certificate_key;
# do not parse the certificate on each request
ssl_certificate_cache max=2;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
listen 443 quic;
listen [::]:443 quic;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
add_header X-Protocol $server_protocol always;
server_name www.example.com;
return 301 https://example.com$request_uri;
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_prefer_server_ciphers off;
acme_certificate letsencrypt;
ssl_certificate $acme_certificate;
ssl_certificate_key $acme_certificate_key;
# do not parse the certificate on each request
ssl_certificate_cache max=2;
}
然后验证 Nginx 配置并重新加载：
sudo nginx -t
sudo nginx -s reload
此时，在默认的 Nginx 日志文件 /var/log/nginx/access.log 中可以看到 Let's Encrypt 验证服务器的请求记录：
23.178.112.210 - - [15/Jan/2026:16:08:18 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
34.212.137.78 - - [15/Jan/2026:16:08:18 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
18.222.179.58 - - [15/Jan/2026:16:08:18 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
16.171.19.61 - - [15/Jan/2026:16:08:18 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
13.228.72.222 - - [15/Jan/2026:16:08:18 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2600:3000:2710:200::81 - - [15/Jan/2026:16:08:20 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2600:1f14:804:fd02:f7fd:3c68:dec7:a062 - - [15/Jan/2026:16:08:20 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2600:1f16:269:da00:c9ce:508c:ea69:9c2 - - [15/Jan/2026:16:08:20 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2a05:d016:39f:3101:8b83:62b8:2603:d15d - - [15/Jan/2026:16:08:20 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
2406:da18:85:1401:1f69:967a:a988:cdc8 - - [15/Jan/2026:16:08:20 +0000] "GET /.well-known/acme-challenge/blablablablablablablablablablablablablablab HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
等待数秒后即可访问 https://example.com/ 了。
如果要给 IP 地址签发证书，则需要在 acme_issuer letsencrypt {} 段里添加一行 profile shortlived;，并且 server_name 必须写入完整的 IP 地址，不能直接用 server_name _ 哦。
不过目前 nginx-acme 最新版本 0.3.1 签发 IP 证书还是会失败，开发版已经修复，应该需要等下一个版本才能使用。
目前最新版本已经支持 IP 地址证书的签发，可以在 accept_terms_of_service; 下方加入一条 profile shortlived; 并且自行修改 server_name example.com; 为你的 IP 地址，比如 server_name 192.0.2.2 2001:db8::2; 即可。
读者们在使用过程中如果遇到问题，可以在 V2EX 交流讨论：
2025-12-18 00:13:37
本文将介绍使用 acme.sh 配置 Let's Encrypt 为 IP 地址签发 SSL 证书。
之前写过一篇使用 acme.sh 签发证书的教程，但在很长一段时间里，Let's Encrypt 只能给域名签发证书。
经过几个月的测试之后，现在终于可以对 IP 地址 下手了。
在很多场景下，我们并不一定需要域名，但确实需要 HTTPS。比如：
直接通过 IP 提供 DoH 服务，避免「为了安全先做一次不安全的域名解析」这种哲学问题。
默认站点只暴露 IP，不暴露真实域名，顺便还能挡掉一部分不太礼貌的爬虫。
临时起个服务，只想加个锁，不想再去 DNS 那边折腾。
有些域名不太想出现在公开日志里，低调一点总是好的。
首先更新 acme.sh 到最新版本：
acme.sh --upgrade
因为 IP 证书目前只能通过 http-01 和 tls-alpn-01 方式进行验证，所以你需要检查服务器的防火墙，设置允许 TCP 80 和 TCP / UDP 443 端口在公网可以访问。
这里我只介绍在 Nginx 下的配置吧，我们可以直接写入 80 端口的默认配置：
如果你在 Debian 或 Ubuntu 下安装 Nginx，可以直接覆盖 /etc/nginx/sites-available/default 文件：
server {
# Listen on port 80 for all IPv4 and IPv6 addresses
listen 80 default_server;
listen [::]:80 default_server;
# Match all domain names
server_name _;
# Merge Let's Encrypt and SSL verification path configuration
location ~ ^/.well-known/(acme-challenge|pki-validation)/ {
add_header Content-Type text/plain;
root /var/www/letsencrypt;
}
# Redirect all other HTTP requests to HTTPS using 301 permanent redirect
location / {
return 301 https://$host$request_uri;
}
}
然后创建两个目录并重新加载 Nginx：
mkdir -p /var/www/letsencrypt
mkdir -p /etc/nginx/ssl
nginx -t
nginx -s reload
假设你服务器的 IP 地址是 192.0.2.2 和 2001:db8::2：
acme.sh --issue --server letsencrypt -d 192.0.2.2 -d 2001:db8::2 \
-w /var/www/letsencrypt \
--certificate-profile shortlived \
--days 3
注意这里我们必须使用 shortlived 这个 Profile，因为 Let's Encrypt 的 IP 证书有效期只有 6.66666 天（160 小时），同时 acme.sh 需要更短的时间来进行检查更新证书，所以可以设置 --days 3 参数，让它 3 天检查并更新一次，你也可以设置 4 或 5，但是不要设置 6，否则可能证书过期了都没更新哦。
执行命令以后会看到类似的申请成功返回：
[Wed Dec 17 05:46:28 AM UTC 2025] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Dec 17 05:46:28 AM UTC 2025] Multi domain='IP:192.0.2.2,IP:2001:db8::2'
[Wed Dec 17 05:46:30 AM UTC 2025] Getting webroot for domain='192.0.2.2'
[Wed Dec 17 05:46:30 AM UTC 2025] Getting webroot for domain='2001:db8::2'
[Wed Dec 17 05:46:30 AM UTC 2025] Verifying: 192.0.2.2
[Wed Dec 17 05:46:31 AM UTC 2025] Pending. The CA is processing your order, please wait. (1/30)
[Wed Dec 17 05:46:34 AM UTC 2025] Success
[Wed Dec 17 05:46:34 AM UTC 2025] Verifying: 2001:db8::2
[Wed Dec 17 05:46:35 AM UTC 2025] Pending. The CA is processing your order, please wait. (1/30)
[Wed Dec 17 05:46:38 AM UTC 2025] Success
[Wed Dec 17 05:46:38 AM UTC 2025] Verification finished, beginning signing.
[Wed Dec 17 05:46:38 AM UTC 2025] Let's finalize the order.
[Wed Dec 17 05:46:38 AM UTC 2025] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/blablablablablablablabla/blablablablablablablabla'
[Wed Dec 17 05:46:41 AM UTC 2025] Downloading cert.
[Wed Dec 17 05:46:41 AM UTC 2025] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/blablablablablablablabla'
[Wed Dec 17 05:46:42 AM UTC 2025] Cert success.
-----BEGIN CERTIFICATE-----
blablablablablablablablablablablablablablablablablablabla
-----END CERTIFICATE-----
[Wed Dec 17 05:46:42 AM UTC 2025] Your cert is in: /root/.acme.sh/192.0.2.2_ecc/192.0.2.2.cer
[Wed Dec 17 05:46:42 AM UTC 2025] Your cert key is in: /root/.acme.sh/192.0.2.2_ecc/192.0.2.2.key
[Wed Dec 17 05:46:42 AM UTC 2025] The intermediate CA cert is in: /root/.acme.sh/192.0.2.2_ecc/ca.cer
[Wed Dec 17 05:46:42 AM UTC 2025] And the full-chain cert is in: /root/.acme.sh/192.0.2.2_ecc/fullchain.cer
然后我们可以把申请好的证书放在 /etc/nginx/ssl 目录：
mkdir -p /etc/nginx/ssl
acme.sh --install-cert -d 192.0.2.2 \
--key-file /etc/nginx/ssl/ip.key \
--fullchain-file /etc/nginx/ssl/ip.crt \
--ca-file /etc/nginx/ssl/ip.ca.crt \
--reloadcmd "systemctl restart nginx"
安装完证书后我们即可配置 Nginx 默认的 443 端口了，你可以把这段配置一起放入 /etc/nginx/sites-available/default 文件：
# HTTPS Server block - Handle all HTTPS requests
server {
# Standard TLS listening
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
# HTTP/2 protocol support
http2 on;
# HTTP/3 QUIC protocol support
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
add_header X-Protocol $server_protocol always;
# Match all domain names
server_name _;
return 403;
# modern configuration
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_prefer_server_ciphers off;
ssl_certificate /etc/nginx/ssl/ip.crt;
ssl_certificate_key /etc/nginx/ssl/ip.key;
}
然后检查并重新加载 Nginx：
nginx -t
nginx -s reload
一切就绪以后就可以直接访问 https://192.0.2.2/ 并返回 403 错误页面，我们可以看到证书里 Subject Alt Names 字段也显示 IP Address 了：
读者们在使用过程中如果遇到问题，可以在 V2EX 交流讨论或在下方评论：
2025-11-04 01:01:40
RDAP.SS 是一个基于 RDAP 协议的 Whois 查询网站，本文介绍 RDAP 协议以及如何使用。
RDAP，全称 Registration Data Access Protocol，由 IETF（互联网工程任务组）制定，主要用于查询以下注册信息：
它定义在 RFC 7480、7481、7482、7483、7484 等系列标准中。
以下是对两者主要区别的总结：
| 比较项目 | WHOIS | RDAP |
|---|---|---|
| 传输协议 | 基于 TCP 文本协议 | 基于 HTTPS RESTful API |
| 数据格式 | 纯文本、非结构化 | JSON 格式、结构化 |
| 国际化支持 | 差，编码不统一 | 完全支持 UTF-8 |
| 安全性 | 无加密、无认证 | 支持 HTTPS、OAuth |
| 分布式查询 | 依靠人工跳转 | 内置 bootstrap 机制，可自动重定向至正确注册局 |
| 标准化程度 | 各注册局格式不同 | 格式统一，易于机器读取与解析 |
在传统的 Whois 协议中，用户需要给 Whois 服务器的 43 端口发送查询，然后 Whois 服务器返回纯文本的结果。
这导致了传统的 Whois 协议有几个无法修补的劣势：
传统的 Whois 没有统一的查询和返回 API，只有简单的文本命令，这导致每家注册局返回的信息格式不一致，例如有的字段写作 Registrant Email，有的写作 Contact Email。这给开发者带来了巨大的解析工作量，需要为不同注册局甚至注册商编写对应的匹配规则。
TCP 43 端口使用明文传输，任何中间节点（包括运营商）都能看到查询内容。🤷♂️ 这在 2025 年已经难以被接受。
Whois 服务器只能识别查询的 IP 地址，无法针对单个用户分配权限或进行身份区分，安全设置也只能基于 IP 层面。
Whois 客户端需要为每个 TLD 手动配置对应的 Whois 服务器，缺乏类似 RDAP 的自动 bootstrap 机制。
而 RDAP 协议完美的弥补了这些劣势：
RDAP 返回的数据是结构化的 JSON，字段统一定义，例如：
{
"objectClassName": "domain",
"ldhName": "example.com",
"status": ["active"],
"entities": [...]
}
这让程序能直接解析字段，无需依赖正则或人工格式识别。
RDAP 基于 HTTP/HTTPS 的 RESTful API，支持 GET 请求、分页、过滤等现代查询方式。
例如：
GET https://rdap.verisign.com/com/v1/domain/example.com
即可从注册局调用 example.com 的信息
RDAP 客户端无需知道具体注册商，它会根据 IANA 的 bootstrap 数据自动跳转到正确的注册局或 RIR
IANA 的 Bootstrap 数据是公开的，可在以下地址访问：
按照 RDAP.org 的统计，目前大约有 77% 的注册局已经接入了 RDAP 协议，除了少部分 TLD 需要手工添加 RDAP 服务器，大部分已经都接入了 IANA 的 bootstrap 数据。
RDAP 强制使用 HTTPS，保障查询与返回内容的完整性与保密性。防止中间人攻击与数据监听。
如有需要，注册局还可以通过 OAuth 2.0 或 Token 认证实现访问控制，根据用户身份（如公众、注册商或执法机构）返回不同级别的信息。这非常契合 GDPR 等隐私法规的要求。
RDAP 支持使用 extensions（扩展字段），注册局可以在标准字段外添加自定义信息，而不会破坏兼容性。
例如：
"rdapConformance": ["rdap_level_0", "icann_rdap_technical_implementation_guide_0"]
基于 RDAP 的优势，我使用 Claude Code 开发了一个基于 RDAP 协议的 Whois 查询网站： RDAP.SS
技术栈：
目前支持如下格式的 Whois 查询：
仅当对应的 TLD 注册局支持 RDAP 协议时，域名查询才可用；未支持的注册局会降级为传统 Whois 协议返回结果。
如果在使用过程中遇到问题，请随时在 GitHub 提交 issue。
2025-10-21 13:45:49
本文将指导如何在 Debian 下使用 extrepo 配置第三方软件源。
extrepo 用于管理 Debian 中的外部软件源。
在没有 extrepo 之前，想要使用未被 Debian 官方打包的软件，用户通常需要手动编写 APT 配置文件、以 root 身份运行未经签名的脚本，或安装一个包含所有系统配置的未签名 .deb 包。
遗憾的是，这些方法都不是很安全。
打个比方，我们要添加 Docker 的软件源，有三种方式。
第一种是传统的 One-Line Style：
curl -sSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://download.docker.com/linux/debian $(lsb_release -sc) stable" | sudo bash -c 'cat > /etc/apt/sources.list.d/docker-ce.list'
sudo apt update
sudo install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y
第二种是新的 DEB822 格式：
curl -sSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
sudo bash -c 'cat > /etc/apt/sources.list.d/docker-ce.sources << EOF
Components: stable
Architectures: $(dpkg --print-architecture)
Suites: $(lsb_release -cs)
Types: deb
Uris: https://download.docker.com/linux/debian
Signed-By: /usr/share/keyrings/docker-ce.gpg
EOF'
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y
第三种方法则更为简单粗暴，直接运行脚本：
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
在以上这些方法中（包括第三种脚本方式），我们都需要手动下载并导入 GPG 密钥，创建必要的 APT 配置文件，更新软件列表，然后再安装软件。而我们推荐使用 extrepo 的话，只需要简单的三个命令即可完成整个过程。
Debian Stable 下直接用如下命令安装 extrepo 即可：
sudo apt update
sudo apt install extrepo -y
接着我们就可以启用比如 Docker CE 的仓库源：
sudo extrepo enable docker-ce
然后更新系统并安装 Docker：
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y
此时我们会发现在 /etc/apt/sources.list.d 目录中多了一个 extrepo_docker-ce.sources 文件：
# cat /etc/apt/sources.list.d/extrepo_docker-ce.sources
Suites: trixie
Types: deb
Uris: https://download.docker.com/linux/debian
Components: stable
Architectures: amd64 arm64 armhf s390x ppc64el
Signed-By: /var/lib/extrepo/keys/docker-ce.asc
换句话说，extrepo 帮我们完成了以下工作：
对比之前的几种方法，你可能还需要满大街找配置命令，找脚本命令，现在只要敲几行命令就可以搞定，何乐而不为呢？
看到这里读者可能有疑问，extrepo 的数据又是谁维护的呢？它是由 Debian External Repositories Team 维护，成员主要为志愿者（包括本文作者），数据本身也有个仓库叫做 extrepo-data。
我个人维护了一些仓库，包括 Redis，MariaDB，N.WTF 等，你可以从这里看到我的 commits。
任何人都可以对这个 Git 仓库做出贡献，而且 YAML 语法也十分容易上手，你可以参考默认的模板文件。
需要查看完整的第三方软件源列表的话，你可以在这里浏览所有的第三方仓库的 .yaml 文件。
了解了 extrepo 的机制和优势后，我们再来总结一下。
总之，使用 extrepo 是一种既安全又方便的添加第三方软件源的方法。
它的主要优点在于：
比如，使用 extrepo 时，只需运行 extrepo enable docker-ce 和 extrepo update docker-ce，它就会自动刷新 Docker CE 仓库的 GPG 密钥和 URI。
不过，extrepo 也有一定的缺点：
