トラブルシューティング — クイック診断集
// QUICK TROUBLESHOOT — 症状別 first-aid コマンド / 最終更新: 2026-05-14
運用中 困ったときの first response 集。 「これ試してダメなら個別ページへ」
2026-05-14 構成前提: WG は maguro 側に移植済 (wg-clients / wg-customers / wg-storage)。 NC + mikyun-portal も maguro。 R640 は WP公開 + nginx SNI router 専用。 Collabora は fabric 直結。
1. WG で接続できない
# maguro でハンドシェイク確認 ssh maguro@192.168.70.30 sudo wg show wg-clients # クライアント VPN sudo wg show wg-customers # 業務カスタマー sudo wg show wg-storage # ストレージ用 # 最近 handshake してるか sudo wg show wg-clients latest-handshakes # RTX1300 で NAT 確認 (telnet/ssh で RTX1300 へ) show nat descriptor address 20000 # 20000/10 udp 54024 → 192.168.70.30:54024 (wg-clients) # 20000/13 udp 61001 → 192.168.70.30:61001 (wg-customers) # 20000/14 udp 62001 → 192.168.30.30:62001 (wg-storage) # パケットキャプチャ sudo tcpdump -i any -n udp port 54024
チェックポイント:
- ✓ RTX1300 NAT が maguro 側 (192.168.70.30) を指してるか (旧R640 192.168.20.21 のまま残ってないか)
- ✓ maguro 側
wg-quick@wg-clientsが active か - ✓ クライアント側 PSK / endpoint が
vpn.k2-o.net:54024か
2. Nextcloud にアクセスできない (403)
# maguro 側で nginx vhost 確認 ssh maguro@192.168.70.30 grep -E "allow|deny" /etc/nginx/sites-available/cloud.k2-o.net # 期待される allow: # 192.168.20.0/24 (社内VLAN20) # 192.168.30.21 (R640 SNI 経由分) # 10.200.0.0/16 (wg-clients ピア) # 173.0.0.0/29 (fabric) # 119.26.175.225 (外部経由バックアップ) # trusted_domains 確認 sudo docker exec -u www-data nextcloud-stack-app-1 \ php occ config:system:get trusted_domains # nginx アクセスログ (source IP 確認) sudo tail -f /var/log/nginx/access.log | grep cloud.k2-o.net
注意: R640 SNI passthrough を経由すると source IP が
192.168.30.21 (R640 出口) に置換される。 これを allow から消すと 内部LANユーザー全員が 403 になる。3. Nextcloud が白画面のまま
# maguro 側 ssh maguro@192.168.70.30 sudo docker ps | grep nextcloud-stack # overwriteprotocol が https か確認 sudo docker exec -u www-data nextcloud-stack-app-1 \ php occ config:system:get overwriteprotocol # 違ったら修正 sudo docker exec -u www-data nextcloud-stack-app-1 \ php occ config:system:set overwriteprotocol --value=https # Docker MariaDB の生存確認 sudo docker exec nextcloud-stack-db-1 mysqladmin ping # nginx エラーログ sudo tail -f /var/log/nginx/error.log
4. Collabora でドキュメントが開かない
# 1. hirame の Collabora が動いてるか ssh hirame@192.168.10.40 docker ps | grep collabora docker logs --tail 30 collabora # 2. Discovery が正しい URL を返すか curl -s http://173.0.0.10:9980/hosting/discovery | grep urlsrc | head -3 # urlsrc="https://office.wan-secure.net/browser/..." が正 # 3. Collabora → maguro fabric 接続確認 (現用経路) docker exec collabora getent hosts cloud.k2-o.net # 173.0.0.5 cloud.k2-o.net (--add-host で固定済) が正 # 4. maguro 側で WOPI ログ確認 ssh maguro@192.168.70.30 sudo tail -f /var/log/nginx/access.log | grep wopi # remote_addr が 173.0.0.6 (hirame SM-fabric IF) なら正常
詳細は「障害・トラブル (id:19)」ページの Collabora 統合記録参照。 過去の苦戦ポイントが全部書いてある。
5. R640 nginx が落ちた / katuocloud.com が開かない
# 外部から curl -sI https://katuocloud.com/ | head -5 # R640 内部から ssh katuo@192.168.20.21 sudo systemctl status nginx sudo nginx -t # 文法チェック sudo journalctl -u nginx --since "10 min ago" --no-pager # stream module + ssl_preread が読み込めてるか sudo nginx -V 2>&1 | tr ' ' '\n' | grep stream # inner WP (127.0.0.1:8443) の生存 curl -ksI https://127.0.0.1:8443/ | head -5 # WP DB 生存 sudo systemctl status mariadb mysql -uroot -e "USE katuocloud_wp; SHOW TABLES" | head
6. 証明書が期限切れそう / 切れた
# R640 (apt certbot) sudo certbot certificates | grep -E "Certificate Name|Expiry" # maguro (snap certbot) sudo certbot certificates | grep -E "Certificate Name|Expiry" # 手動更新 (R640) sudo certbot renew --cert-name katuocloud.com --force-renewal sudo systemctl reload nginx # 手動更新 (maguro) sudo certbot renew --cert-name cloud.k2-o.net --force-renewal sudo systemctl reload nginx
cert-watch (06:30 daily) が 残14日で警告飛ばすので、 通常はそれで気付ける。 過去の DuckDNS 期限切れ事件以来、 監視体制を強化した。
7. ディスクが満杯
# 全ホスト共通
df -h | awk '$5+0 > 80 {print}'
# maguro storage
ssh maguro@192.168.70.30
df -h /srv/storage
du -sh /srv/storage/* 2>/dev/null | sort -h | tail -10
du -sh /srv/storage/nextcloud-data/* 2>/dev/null | sort -h | tail -10
# R640 /mnt/data
ssh katuo@192.168.20.21
df -h /mnt/data
du -sh /mnt/data/* 2>/dev/null | sort -h | tail
ls -lt /mnt/data/backup/wp/katuocloud_wp/ | head # 古いバックアップ確認
supermicro-watch は 使用率 90%+ で通知してくれる。 alert 来てから慌てるのではなく、 月次点検で 80% 超えたら理由を調べる。
8. maguro LUKS 自動アンロックが失敗した
maguro の LUKS auto-unlock は keyfile 方式 (/etc/cryptsetup-keys.d/) + bcache + storage-cache (NVMe md127) の組み合わせ。
# 状態確認 ssh maguro@192.168.70.30 sudo cryptsetup status raid1-4 sudo cryptsetup status storage-cache ls -lh /etc/cryptsetup-keys.d/ # 手動アンロック (緊急時) sudo cryptsetup luksOpen /dev/sdX raid1 sudo cryptsetup luksOpen /dev/sdY storage-cache # bcache attach echo /dev/bcache0 > /sys/fs/bcache/register
過去の既知問題: 旧 maguro 時代、 initramfs で USB キーボードドライバが未読込で LUKS パスフレーズ入力不可になる事件があった。 現在は keyfile auto-unlock に切り替えたため発生しない。 keyfile が壊れたときは USB キーボード問題が再発する可能性あるので留意。
9. R640 PERC / SMART アラート
ssh katuo@192.168.20.21 # perc-watch が拾った最新 sudo journalctl -u perc-watch.service --since "1 day ago" --no-pager | tail -50 # 手動 SMART (megaraid 配下) sudo smartctl -a -d megaraid,0 /dev/bus/0 sudo smartctl -a -d megaraid,1 /dev/bus/0 # ... 0〜7 (SAS×8) # NVMe sudo smartctl -a /dev/nvme0 sudo smartctl -a /dev/nvme1 # megaraid kernel ログ sudo dmesg | grep -i megaraid | tail
10. Telegram 通知が来ない
# 全ホスト共通: telegram_send のテスト echo "test from $(hostname)" | telegram_send --stdin # bot token / chat_id 確認 cat /etc/telegram_send.conf # 監視 unit から手動呼び出し sudo systemctl start perc-watch.service # R640 sudo systemctl start supermicro-watch.service # maguro sudo journalctl -u perc-watch.service -e --no-pager
クイック判定フロー
症状発生
↓
┌───────┴───────┐
│ どこから繋がらない? │
└───────┬───────┘
↓
┌──────┼──────┐
↓ ↓ ↓
外部 内部 内部
全部 LAN WG
ダメ のみ のみ
↓ ↓ ↓
DNS/ nginx maguro
RTX allow wg-quick
確認 確認 確認
関連ページ: 「障害・トラブル (id:19)」(過去の詳細記録) / 「運用 switch コマンド (id:313)」(apt update 系) / 「運用・保守 (id:858)」(日次/週次点検)