UbuntuにVNCを入れるとき、多くの人がつまずくのは2つの点です。
1つは、接続できるのに画面が黒いままになる問題です。もう1つは、5901番ポートをインターネットに開けるべきか迷う問題です。
どちらも原因は思ったより単純でした。黒い画面はネットワークではなくxstartupの設定の問題で、ポートはそもそも開ける必要がありませんでした。
AWS EC2のUbuntuサーバーでGUIのテストが必要になり、TigerVNCを自分でインストールしました。そのときの過程をそのまままとめます。
UbuntuサーバーでVNCが必要になるのはどんなとき？
サーバーの運用はSSHで足ります。VNCが必要なのは、ブラウザの認証フローやGUIアプリの実際の画面を直接見なければならないときだけです。
普段のサーバー管理はSSHで行っていました。VNCを入れたのは、常時使えるリモートデスクトップが欲しかったからではありません。
クラウドに立てたUbuntuで、ブラウザとGUIアプリを直接確認する必要がある開発・テスト期間があったからです。
認証やリダイレクトの流れを目で確かめる作業や、GUIアプリが実際にどんな画面状態なのかを確認する作業でした。
そのため、GUIが必要な期間だけTigerVNCと軽量なデスクトップ環境を追加しました。CLIで済む作業なら、今もVNCはインストールしません。
XfceとTigerVNCのインストールと初期設定
UbuntuでVNCのリモートデスクトップを使うには、軽量デスクトップ環境のXfceとTigerVNCサーバーを入れ、vncpasswdで接続用パスワードを設定します。
当時の主な環境はUbuntu 22.04 LTSでした。
以前よく参照されていた20.04は、2025年5月31日で標準サポートが終了しています。今から新しく構成するなら、22.04か24.04 LTSを基準にするのがよいと考えています。
パッケージのインストール（Xfce、TigerVNC）
まずパッケージ一覧を更新し、XfceとTigerVNCをインストールします。
sudo apt update sudo apt install -y xfce4 xfce4-goodies tigervnc-standalone-server
インストール自体は長くかかりません。時間がかかるのは、この次の段階です。
vncpasswdで接続パスワードを設定
インストールが終わったら、vncpasswdでVNC接続用のパスワードを作ります。
vncpasswd
このパスワードはLinuxアカウントのパスワードとは別物です。VNCクライアントで接続するときに入力する値です。
TigerVNCで接続後に黒い画面になる原因は？
VNC接続後に黒い画面しか出ないなら、ネットワークより先に~/.vnc/xstartupの実行権限とセッション起動コマンドを疑うべきです。
最初にぶつかったのが、まさにこの問題でした。
VNCのプロセスは起動していて、クライアントからの接続もできていました。そのため、最初はネットワーク側を疑いませんでした。
調べてみると、~/.vnc/xstartupがデスクトップセッションを正しく起動できていませんでした。実行権限とセッション起動コマンドを整理し、VNCセッションを起動し直すと解決しました。
この経験のあと、切り分けの順番を変えました。まず「接続自体ができない」問題と「接続後に黒い画面だけが出る」問題を分けて見ます。
前者ならネットワーク、ファイアウォール、サービスの状態を確認します。後者ならxstartupを先に確認します。
最初にこの過程をすべて経験したときは、試行錯誤を含めて約40〜50分かかりました。
この時間は、VNCのインストールから実際の接続までの合計です。途中にデスクトップ環境の設定、xstartupの作成、黒い画面、権限とセッションの修正、SSHトンネルがありました。
2つ目の環境では原因がもう分かっていたので、20分以内で終わりました。
xstartupの実行権限とセッション起動コマンドを整える
~/.vnc/xstartupに実行権限を付け、デスクトップセッションを起動するコマンドが正しく入っているかを確認します。
chmod +x ~/.vnc/xstartup
xstartupには、Xfceのセッションを起動するコマンドが正常に実行されるように書かれている必要があります。
この設定が正しくないと、VNCサーバーは正常に動いていても画面だけが真っ黒になります。
5901番ポートは開けるべき？SSHトンネルで接続する
VNCのポート（5901）をインターネットに直接開ける必要はありません。SSHトンネルでローカルのポートをサーバー内部につなげば、セキュリティグループにVNC用のポートを追加しなくて済みます。
VNCが使うRFBプロトコル自体は、通信を暗号化しません。画面データや認証のやり取りがそのまま流れるということです。
ポートをインターネットに直接開けず、SSHトンネルで包む理由はここにあります。
一度、5901番ポートを直接開ける必要があると考えて、先にAWSのセキュリティグループを変更しようとしたことがあります。
結局そうはしませんでした。VNCのポートをインターネットに直接さらさず、SSHトンネルを使いました。
接続の形は、おおよそローカルのlocalhost:5901 → SSH → サーバーのlocalhost:5901です。セキュリティグループでは、VNC用の5901をインターネット全体に公開しませんでした。
VNCがつながらないからといって、先に5901をインターネットに開ける必要はありませんでした。
必要だったのはポートの公開ではなく、正常なデスクトップセッションとSSHトンネルでした。
VNCサーバーをsystemdのサービスにするには？
VNCサーバーをsystemdのサービスとして登録すれば、サーバーの再起動後にvncserverコマンドを手で打ち直す必要がなくなります。
[email protected]という形でユニットファイルを作り、systemctlで有効化します。
すると、サーバーが再起動してもVNCセッションが自動で立ち上がります。そのたびにSSHで入ってvncserverコマンドを打つ手間がなくなります。
sudo systemctl enable [email protected] sudo systemctl start [email protected] sudo systemctl status [email protected]
statusコマンドで、セッションが正常に起動したかをすぐに確認できます。
VNCの代わりに何を使う？用途別の選び方
コード作業ならSSHやリモート開発環境、Web UIの結果確認ならヘッドレスブラウザを使います。Linux GUI全体が必要なときだけVNCを選ぶのが合理的だと考えています。
用途によって使い分けています。
| 目的 | おすすめのツール |
|---|---|
| サーバー管理・コード修正 | SSH、VS Code Remote SSH、devcontainer、code-server |
| Web UIの結果確認・ブラウザ自動化 | ヘッドレスブラウザ |
| Linuxデスクトップセッションそのものの確認 | VNC |
コードはSSH系、画面の結果だけならヘッドレスブラウザです。デスクトップセッションそのものが必要なときだけVNCを使います。
X11 forwardingも使ったことがあります。複数のGUIウィンドウを長時間扱う環境では、完全なデスクトップセッションを保つVNCのほうが楽だった場合がありました。
だからといって「UbuntuサーバーにはGUIが必要だ」という立場ではありません。むしろCLIで済む作業なら、VNCはインストールしないほうです。
今は、そのEC2でVNCを常時起動していません。必要なときだけGUI環境を作るやり方に変わりました。
外部に公開したサーバーで常時動かす理由がないなら、VNCデーモンとデスクトップ環境は攻撃対象領域と運用対象を増やすだけだと考えています。
よくある質問
VNCに接続できるのに画面が真っ黒なのはなぜですか？
ネットワークの問題ではなく、多くは~/.vnc/xstartupの設定の問題です。実行権限（chmod +x）と、セッション起動コマンドが正しく入っているかを先に確認します。
VNCのポート（5901）をセキュリティグループで開ける必要はありますか？
いいえ。SSHトンネルでローカルのポートをサーバー内部につなげばよく、5901をインターネットに直接さらす必要はありません。
VNC以外のリモート接続方法はありますか？
目的によります。コード作業ならSSHやリモート開発環境、Web UIの結果確認ならヘッドレスブラウザのほうが簡単です。
Linux GUIの画面全体を見る必要があるときだけ、VNCを検討すれば十分です。
参考資料
- RFC 6143: The Remote Framebuffer Protocol：VNC（RFB）がセッションを暗号化しないことの一次情報
- Canonical: Ubuntu 20.04 LTSの標準サポート終了のお知らせ（英語）：20.04の標準サポート終了日（2025年5月31日）の一次情報
この記事は韓国語の原文をもとにローカライズしたものです: https://jjeongil.tistory.com/2090。