Hướng dẫn Windows (WSL2)

Hermes Agent hiện hỗ trợ cả Windows gốc và WSL2. Trang này trình bày đường dẫn WSL2; để biết bản cài đặt PowerShell gốc, hãy xem Windows (Native) Guide chuyên dụng.

Khi nào nên chọn WSL2 thay vì bản gốc:

• Bạn muốn sử dụng terminal được nhúng của trang tổng quan (tab

/chat

) — khung đó yêu cầu POSIX PTY và chỉ có WSL2.

• Bạn đang thực hiện công việc phát triển nặng về POSIX và muốn các phiên Hermes của bạn chia sẻ cùng hệ thống tệp/đường dẫn như các công cụ phát triển của bạn.
• Bạn đã có môi trường WSL2 và không muốn duy trì cài đặt thứ hai.

Khi tiếng bản địa phù hợp (hoặc tốt hơn):

• Trò chuyện tương tác, cổng (Telegram/Discord/v.v.), bộ lập lịch cron, công cụ trình duyệt, máy chủ MCP và hầu hết các tính năng của Hermes đều chạy nguyên bản trên Windows.
• Bạn không muốn nghĩ đến việc vượt qua ranh giới WSL↔Windows mỗi khi tham chiếu một tệp hoặc mở một URL.

Trong WSL2 thực tế có hai máy tính đang hoạt động: máy chủ Windows của bạn và máy ảo Linux do WSL quản lý. Hầu hết sự nhầm lẫn đều xuất phát từ việc không chắc chắn mình đang sử dụng cái nào vào bất kỳ lúc nào.

Hướng dẫn này đề cập đến các phần của sự phân chia đó ảnh hưởng cụ thể đến Hermes: cài đặt WSL2, nhận các tệp qua lại giữa Windows và Linux, kết nối mạng theo cả hai hướng và những cạm bẫy mà mọi người thực sự gặp phải.

简体中文

Hướng dẫn bằng tiếng Trung về đường dẫn cài đặt tối thiểu được duy trì trên cùng trang này — chuyển qua menu ngôn ngữ (trên cùng bên phải) và chọn 简体中文.

Tại sao lại là WSL2 (so với Windows gốc)

Bản cài đặt Windows gốc chạy trực tiếp trong Windows: terminal Windows của bạn (PowerShell, Windows Terminal, v.v.), đường dẫn hệ thống tệp Windows ( `C:\Users\…

) và các quy trình Windows. Hermes sử dụng Git Bash để chạy các lệnh shell, đó là cách Claude Code và các tác nhân khác xử lý Windows ngày nay - nó vượt qua khoảng cách POSIX-so với Windows mà không cần viết lại toàn bộ.

WSL2 chạy nhân Linux thực trong một máy ảo nhẹ, vì vậy Hermes bên trong nó về cơ bản giống với chạy trên Ubuntu. Điều đó có giá trị khi bạn muốn có một môi trường POSIX thực sự: `fork

,

/tmp

, ổ cắm UNIX, ngữ nghĩa tín hiệu, terminal được PTY hỗ trợ, các shell như

/
`zsh
` và các công cụ như 
`rg

, 
`git

, 
`ffmpeg
` hoạt động theo cách chúng hoạt động trên Linux.

Hậu quả thực tế của WSL2:
- Hermes CLI, cổng, phiên, bộ nhớ, kỹ năng và thời gian chạy công cụ đều nằm trong máy ảo Linux.

- Các chương trình Windows (trình duyệt, ứng dụng gốc, Chrome với hồ sơ đăng nhập của bạn) nằm bên ngoài nó.
- Mỗi khi bạn muốn cả hai nói chuyện — chia sẻ tệp, mở URL, điều khiển Chrome, truy cập máy chủ mô hình cục bộ, đưa cổng Hermes vào điện thoại của bạn — bạn đã vượt qua một ranh giới. Những ranh giới đó chính là nội dung của hướng dẫn này.

## Cài đặt WSL2

Từ **Admin PowerShell** hoặc Windows Terminal:

``` powershell
wsl --install

`
``Trên hộp Windows 10 22H2+ hoặc Windows 11 mới, cài đặt này sẽ cài đặt kernel WSL2, tính năng Nền tảng máy ảo và bản phân phối Ubuntu mặc định. Khởi động lại khi được nhắc. Sau khi khởi động lại, Ubuntu sẽ mở và yêu cầu tên người dùng + mật khẩu Linux - đây là **người dùng Linux mới**, không liên quan đến tài khoản Windows của bạn.

Xác minh rằng bạn thực sự đang sử dụng WSL2 (không phải WSL1 kế thừa):

`powershell
wsl --list --verbose

`
``Bạn sẽ thấy 
`VERSION  2

. Nếu một bản phân phối hiển thị 
`VERSION  1

, hãy chuyển đổi nó:

`powershell
wsl --set-version Ubuntu 2
wsl --set-default-version 2

`
``Hermes không hoạt động đáng tin cậy trên WSL1 - WSL1 dịch các tòa nhà Linux một cách nhanh chóng và một số hành vi (procfs, tín hiệu, mạng) khác với Linux thực.

### Lựa chọn phân phối

Ubuntu (LTS) là thứ chúng tôi thử nghiệm. Debian hoạt động. Arch và NixOS hoạt động cho những người muốn chúng, nhưng trình cài đặt một dòng giả định hệ thống 
`apt
` có nguồn gốc từ Debian - hãy xem [Nix setup guide](/docs/getting-started/nix-setup) để biết đường dẫn đó.

### Kích hoạt systemd (được khuyến nghị)

Cổng Hermes (và bất kỳ thứ gì khác mà bạn muốn tiếp tục chạy) sẽ dễ quản lý hơn với systemd. Trên WSL hiện đại, hãy kích hoạt nó một lần trong bản phân phối của bạn:

`bash
sudo tee /etc/wsl.conf >/dev/null `<<\'EOF\'
[boot]
systemd=true`[interop]
enabled=true
appendWindowsPath=true`[automount]
options = "metadata,umask=22,fmask=11"
EOF

`
``Sau đó từ PowerShell:

`powershell
wsl --shutdown

`
``Mở lại terminal WSL của bạn. 
`ps -p 1 -o comm=
` nên in 
`systemd

.

Tùy chọn gắn 
`metadata
` ở trên rất quan trọng — nếu không có nó, các tệp trên 

/mnt/c/...
` không thể lưu trữ các bit cấp phép Linux thực sự, điều này sẽ phá vỡ những thứ như 
`chmod +x
` trên các tập lệnh trong đường dẫn Windows.

### Cài đặt Hermes bên trong WSL

Khi bạn đã mở shell WSL2:

`bash
curl -fSSL https://raw.GitHubusercontent.com/NousResearch/Hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
Hermes

`
`Trình cài đặt coi WSL2 như Linux thuần túy — không cần gì cụ thể về WSL. Xem [Installation](/docs/getting-started/installation) để biết bố cục đầy đủ.

## Hệ thống tập tin: vượt qua ranh giới Windows ↔ WSL2

Đây là phần khiến nhiều người vấp ngã nhất. Có **hai hệ thống tệp** và vị trí bạn đặt tệp rất quan trọng — về hiệu suất, độ chính xác và những gì công cụ có thể nhìn thấy.`###Hai hướng

| Hướng | Đường dẫn bên trong | Đường dẫn bạn sử dụng |
|---|---|---|
| Đĩa Windows, nhìn từ WSL |

C:\Users\you\Documents
` | 

/mnt/c/Users/you/Documents
` |
| Đĩa WSL, nhìn từ Windows |

/home/you/code
` | 

\\wsl$\Ubuntu\home\you\code
` (hoặc 

\\wsl.localhost\Ubuntu\...
` trên các bản dựng mới hơn) |

Cả hai đều là thật, cả hai đều hoạt động, nhưng chúng **không phải cùng một hệ thống tệp** — chúng được kết nối bằng giao thức mạng 9P bên trong. Điều đó có hiệu suất thực sự và hậu quả ngữ nghĩa.

### Nơi đặt Hermes và các dự án của bạn`**Quy tắc chung: giữ mọi thứ giống Linux bên trong hệ thống tập tin Linux.**
- Bản cài đặt Hermes của bạn (

~/.Hermes/

) — phía Linux. Trình cài đặt đã thực hiện việc này.

- Kho git của bạn mà bạn làm việc từ WSL — phía Linux (

~/code/...

, 

~/projects/...

).
- Mô hình, bộ dữ liệu, venv của bạn — phía Linux.

Bạn nhận được gì khi tuân theo quy tắc này:
- **I/O nhanh.** Các hoạt động trên 

/mnt/c/...
` trải qua 9P và chậm hơn 10–100× so với ext4 gốc. 
`git status
` trên kho lưu trữ tệp 10k mang lại cảm giác tức thì trong 

~/code
` có thể mất hơn 15 giây trong 

/mnt/c

.
- **Quyền chính xác.** Các bit cấp phép Linux là mô phỏng hiệu quả nhất trên 

/mnt/c

. Những trường hợp như 
`SSH
` từ chối khóa có "quyền xấu" hoặc 
`chmod +x
` bị lỗi âm thầm là phổ biến.
- **Trình theo dõi tệp đáng tin cậy.** inotify trên 9P không ổn định — trình theo dõi tệp (máy chủ nhà phát triển, trình chạy thử nghiệm) thường xuyên bỏ lỡ các thay đổi trên 

/mnt/c

.
- **Không có bất ngờ nào về phân biệt chữ hoa chữ thường.** Đường dẫn Windows theo mặc định không phân biệt chữ hoa chữ thường; Linux phân biệt chữ hoa chữ thường. Các dự án có cả 
`Readme.md
` và 
`README.md
` hoạt động khác nhau tùy thuộc vào việc bạn đứng về phía nào.

Chỉ đặt mọi thứ trên 

/mnt/c
` khi bạn **cần** một tệp để tồn tại trên Windows - ví dụ: bạn muốn mở tệp đó từ ứng dụng GUI của Windows hoặc DevTools MCP của Windows Chrome cần thư mục hiện tại là đường dẫn mà Windows có thể truy cập.

### Lấy file qua lại`**Từ Windows → vào WSL:** dễ nhất là mở Explorer và nhập 

\\wsl.localhost\Ubuntu
` vào thanh địa chỉ. Sau đó, bạn có thể kéo-thả vào 

\home\<you\...

. Hoặc từ PowerShell:

``` powershell
wsl cp /mnt/c/Users/you/Downloads/file.pdf ~/incoming/

`
``**Từ WSL → vào Windows:** sao chép vào 

/mnt/c/Users/<you>/...
` và nó sẽ hiển thị ngay trong Windows Explorer:

`bash
cp ~/reports/output.pdf /mnt/c/Users/you/Desktop/

`
``**Mở tệp WSL trong ứng dụng Windows** (trình chỉnh sửa GUI, trình duyệt, v.v.): sử dụng 
`explorer.exe
` hoặc 
`wslview

:

`bash
sudo apt install wslu     # once — gives you wslview, wslpath, wslopen, etc.
wslview ~/reports/output.pdf    # opens with the Windows default handler
explorer.exe .                  # opens the current WSL dir in Windows Explorer

`
``**Chuyển đổi đường dẫn giữa hai vũ trụ:**

`bash
wslpath -w ~/code/project        # → \\wsl.localhost\Ubuntu\home\you\code\project
wslpath -u 'C:\Users\you'        # → /mnt/c/Users/you

`

### Kết thúc dòng, BOM và git

Nếu bạn chỉnh sửa các tệp ở phía Windows bằng trình chỉnh sửa Windows, chúng có thể nhận được phần cuối dòng 
`CRLF

. Khi 
`bash
` hoặc Python ở phía Linux đọc chúng, các tập lệnh shell bị hỏng với 
`bad interpreter: /bin/bash^M
` và Python có thể bị lỗi trên các tệp 

.env
` của BOM.

Cách khắc phục là cấu hình git lành mạnh bên trong WSL (không phải trên Windows):

`bash
git config --global core.autocrlf input
git config --global core.eol lf

`
``Đối với các tệp đã có CRLF:

`bash
sudo apt install dos2unix
dos2unix path/to/script.sh

`

### "Sao chép bên trong WSL hoặc trên 

/mnt/c

?"

Sao chép bên trong WSL. Luôn luôn, trừ khi bạn có lý do cụ thể để không làm vậy. Một quy trình làm việc điển hình của Hermes (
`Hermes chat

, công cụ gọi 
`rg

/
`ripgrep
` là kho lưu trữ, trình theo dõi tệp, cổng nền) sẽ nhanh hơn đáng kể và đáng tin cậy hơn so với 

~/code/myrepo
` so với 

/mnt/c/Users/you/myrepo

.

Một ngoại lệ: **Cầu nối MCP khởi chạy các tệp nhị phân Windows.** Nếu bạn đang sử dụng 
`chrome-devtools-MCP
` đến 
`cmd.exe
` (xem [MCP guide: WSL → Windows Chrome](/docs/guides/use-MCP-with-Hermes#wsl2-bridge-Hermes-in-wsl-to-Windows-chrome)), Windows có thể khiếu nại với cảnh báo 
`UNC
` nếu thư mục làm việc hiện tại của Hermes là 

~

. Trong trường hợp đó, hãy khởi động Hermes từ đâu đó trong 

/mnt/c/
` để quy trình Windows có ký tự ổ đĩa cwd.

## Kết nối mạng: WSL ↔ Windows

WSL2 chạy trong một máy ảo nhẹ với ngăn xếp mạng riêng. Điều đó có nghĩa là 
`localhost
` bên trong WSL **không giống với** 
`localhost
` trên Windows — chúng là hai máy chủ riêng biệt theo quan điểm của mạng. Đối với mỗi dịch vụ, bạn cần phải quyết định hướng giao thông di chuyển và chọn cây cầu phù hợp.

Hai trường hợp xảy ra liên tục.### Trường hợp 1 - Hermes trong WSL nói chuyện với một dịch vụ trên Windows

Phổ biến nhất: bạn đang chạy **OLlama, LM Studio hoặc máy chủ Llama trên Windows** và Hermes (bên trong WSL) cần phải tấn công nó.

Cách thực hiện chuẩn mực cho cuộc sống này trong hướng dẫn dành cho nhà cung cấp: **[WSL2 Networking for Local Models →](/docs/integrations/providers#wsl2-networking-Windows-users)**

Phiên bản ngắn:
- **Windows 11 22H2+:** bật chế độ kết nối mạng được phản chiếu (
`networkingMode=mirrored
` trong 

%USERPROFILE%\.wslconfig

, sau đó là 
`wsl --shutdown

). 
`localhost
` sau đó hoạt động theo cả hai hướng.

- **Bản dựng Windows 10 trở lên:** sử dụng IP máy chủ Windows (cổng mặc định của mạng ảo WSL) và đảm bảo máy chủ trên Windows liên kết với 
`0.0.0.0

, không chỉ 
`127.0.0.1

. Tường lửa Windows thường cũng cần một quy tắc cho cổng.

Để xem bảng đầy đủ (địa chỉ liên kết OLlama / LM Studio / vLLM / SGLang, một lớp quy tắc tường lửa, trình trợ giúp IP động, cách giải quyết tường lửa Hyper-V), hãy nhấp vào liên kết ở trên — đừng sao chép nó.

### Trường hợp 2 - Có gì đó trên Windows (hoặc mạng LAN của bạn) nói chuyện với Hermes trong WSL

Đây là hướng ngược lại và ít được ghi lại ở nơi khác, nhưng đó là những gì bạn cần:
- Sử dụng **trang tổng quan web** của Hermes từ trình duyệt Windows.
- Sử dụng **Máy chủ API tương thích với OpenAI** (được 
`Hermes gateway
` hiển thị khi 
`API_SERVER_ENABLED=true

) từ một công cụ phía Windows. Xem [API Server feature page](/docs/user-guide/features/API-server).
- Thử nghiệm **cổng nhắn tin** (Telegram, Discord, v.v.) trong đó nền tảng ping URL webhook cục bộ — thông thường bạn sẽ sử dụng 
`cloudflared

/
`ngrok
` thay vì chuyển tiếp cổng thô.

#### Trường hợp con 2a: từ chính máy chủ Windows

Trên **Windows 11 22H2+ đã bật chế độ phản chiếu**, không có gì để làm. Có thể truy cập quy trình trong WSL liên kết với 
`0.0.0.0:8080
` (hoặc thậm chí 
`127.0.0.1:8080

) từ trình duyệt Windows tại 
`http://localhost:8080

. WSL tự động xuất bản liên kết trở lại máy chủ.

Trên **chế độ NAT** (Windows 10 / Windows 11 cũ hơn), "chuyển tiếp localhost" mặc định trong WSL2 thường sẽ chuyển tiếp 
`127.0.0.1
` phía Linux liên kết với Windows 
`localhost

, do đó, dịch vụ Hermes bắt đầu bằng 

--host 127.0.0.1
` thường có thể truy cập được dưới dạng 
`http://localhost:3000
` từ Windows. Nếu không:
- Liên kết rõ ràng với 
`0.0.0.0
` bên trong WSL.
- Tìm IP của WSL VM bằng 
`ip -4 addr show eth0 | grep inet
` và nhấn nó từ Windows.

#### Trường hợp con 2b: từ một thiết bị khác trong mạng LAN của bạn (điện thoại, máy tính bảng, PC khác)

Đây là nỗi đau thực sự. Luồng lưu lượng **Thiết bị LAN → Máy chủ Windows → WSL VM** và bạn phải thiết lập cả hai bước nhảy:
1. **Liên kết trên tất cả các giao diện bên trong WSL.** Quá trình lắng nghe trên 
`127.0.0.1
` sẽ không bao giờ có thể truy cập được từ bên ngoài VM. Sử dụng 
`0.0.0.0

.
2. **Chuyển tiếp cổng Windows → WSL VM.** Ở chế độ phản chiếu, việc này diễn ra tự động. Trong chế độ NAT, bạn phải tự thực hiện việc đó trên mỗi cổng trong PowerShell quản trị:

``` powershell

   # Grab the WSL VM's current IP (it changes on every WSL restart under NAT)
   $wslIp = (wsl hostname -I).Trim().Split(' ')[0]

# Forward Windows port 8080 → WSL:8080
   netsh interface portproxy add v4tov4 

     listenaddress=0.0.0.0 listenport=8080 

     connectaddress=$wslIp connectport=8080

# Allow it through Windows Firewall
   New-NetFirewallRule -DisplayName "Hermes WSL 8080" 

     -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

``Loại bỏ sau bằng 
`netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=8080

.
3. **Trỏ thiết bị LAN vào 
`http://<Windows-lan-ip:8080

.**

Vì IP WSL VM trôi đi mỗi lần khởi động lại ở chế độ NAT nên quy tắc một lần chỉ tồn tại cho đến 
`wsl --shutdown
` tiếp theo. Đối với bất kỳ điều gì liên tục, hãy sử dụng chế độ được phản chiếu hoặc đặt bước proxy cổng trong tập lệnh chạy khi đăng nhập Windows.

Đối với webhooks từ các nhà cung cấp dịch vụ nhắn tin trên đám mây (Telegram 
`setWebhook

, sự kiện Slack, v.v.), đừng chống lại việc chuyển tiếp cổng — hãy sử dụng đường hầm 
`cloudflared

. Xem [webhooks guide](/docs/user-guide/messaging/webhooks).

## Chạy dịch vụ Hermes lâu dài trên Windows

Hermes [Tool Gateway](/docs/user-guide/features/tool-gateway) và máy chủ API là các quy trình tồn tại lâu dài. Trong WSL2, bạn có một số tùy chọn để duy trì chúng.

### Bên trong WSL với systemd (được khuyến nghị)

Nếu bạn đã bật systemd theo phần thiết lập ở trên, 
`Hermes gateway
` và máy chủ API sẽ hoạt động theo cách chúng hoạt động trên bất kỳ máy Linux nào. Sử dụng trình hướng dẫn thiết lập cổng:

``` bash
Hermes gateway setup

`
``Nó sẽ đề nghị cài đặt một đơn vị người dùng systemd để cổng tự động xuất hiện khi WSL khởi động.

### Làm cho WSL tự khởi động khi đăng nhập Windows

VM của WSL chỉ tồn tại khi có thứ gì đó đang sử dụng nó. Để giữ cho cổng của bạn có thể truy cập được mà không cần mở cửa sổ đầu cuối, hãy khởi động quy trình WSL khi đăng nhập Windows thông qua Trình lập lịch tác vụ:
- **Kích hoạt:** Khi đăng nhập (người dùng của bạn).

- **Hành động:** Bắt đầu một chương trình
  - Chương trình: 
`C:\Windows\System32\wsl.exe

  - Đối số: 

-d Ubuntu --exec /bin/sh -c "sleep infinity"
``Điều đó giữ cho VM tồn tại để cổng do systemd quản lý vẫn chạy. Trên Windows 11, các luồng tự động khởi động 
`wsl --install --no-launch

 + mới hơn cũng hoạt động; thủ thuật 
`sleep infinity
` là phiên bản di động.

## Truyền qua GPU (mô hình cục bộ)WSL2 hỗ trợ **NVIDIA** GPU nguyên bản kể từ WSL kernel 5.10.43+ — cài đặt trình điều khiển NVIDIA tiêu chuẩn trên Windows (không** cài đặt trình điều khiển NVIDIA Linux bên trong WSL) và 
`nvidia-smi
` bên trong WSL sẽ thấy GPU. Từ đó, các bộ công cụ CUDA, 
`torch

, 
`vLLM

, 
`sglang
` và 
`Llama-server
` được xây dựng dựa trên GPU thực như thường lệ.

Hỗ trợ AMD ROCm và Intel Arc bên trong WSL2 vẫn đang phát triển và nằm ngoài ma trận thử nghiệm của Hermes - nó có thể hoạt động với các trình điều khiển hiện tại nhưng chúng tôi không có công thức để đề xuất.

Nếu bạn đang chạy máy chủ mô hình cục bộ **Windows gốc** (OLlama cho Windows, LM Studio) đã sử dụng GPU của bạn thông qua trình điều khiển Windows thì bạn hoàn toàn không cần chuyển tiếp GPU WSL — chỉ cần làm theo Trường hợp 1 ở trên và truy cập nó qua mạng từ WSL.

## Những cạm bẫy thường gặp`**"Kết nối bị từ chối" với OLlama / LM Studio được lưu trữ trên Windows của tôi.**
Xem [WSL2 Networking](/docs/integrations/providers#wsl2-networking-Windows-users). Chín mươi phần trăm thời gian máy chủ được liên kết với 
`127.0.0.1
` và cần 
`0.0.0.0
` (OLlama: 
`OLlama_HOST=0.0.0.0

) hoặc bạn đang thiếu quy tắc tường lửa.

**Sự chậm chạp nghiêm trọng trên 
`git status
` / 
`Hermes chat
` trong một repo.**
Có thể bạn đang làm việc theo 

/mnt/c/...

. Di chuyển repo sang 

~/code/...
` (phía Linux). Thứ tự cường độ nhanh hơn.

**
`bad interpreter: /bin/bash^M
` trên tập lệnh.**
Kết thúc dòng CRLF từ trình soạn thảo Windows. 
`dos2unix script.sh
` và đặt 
`core.autocrlf input
` trong cấu hình git WSL của bạn.

**Cảnh báo "Đường dẫn UNC không được hỗ trợ" từ các tệp nhị phân Windows được khởi chạy qua MCP.**
Cwd của Hermes nằm trong hệ thống tệp Linux và Windows 
`cmd.exe
` không biết phải làm gì với nó. Khởi động Hermes từ 

/mnt/c/...
` cho phiên đó hoặc sử dụng trình bao bọc 
`cd
` tới đường dẫn có thể truy cập của Windows trước khi gọi tệp thực thi Windows.

**Đồng hồ trôi sau khi ngủ/ngủ đông.**
Đồng hồ của WSL2 có thể bị trễ vài phút sau khi máy chủ tiếp tục từ chế độ ngủ, điều này phá vỡ mọi thứ dựa trên chứng chỉ (API OAuth, HTTPS). Sửa theo yêu cầu:

``` bash
sudo hwclock -s

`
``Hoặc cài đặt 
`ntpdate
` và chạy nó khi đăng nhập.

**DNS ngừng hoạt động sau khi bật chế độ phản chiếu hoặc khi kết nối VPN.**
Chế độ phản chiếu proxy lưu trữ các cài đặt mạng vào WSL — nếu DNS của Windows hoạt động kém (đường hầm phân chia VPN, trình phân giải công ty), WSL sẽ kế thừa điều đó. Cách giải quyết: ghi đè 
`resolv.conf
` theo cách thủ công (đặt 
`generateResolvConf=false
` trong 

/etc/wsl.conf

, sau đó ghi 

/etc/resolv.conf
` của riêng bạn bằng 
`1.1.1.1
` hoặc DNS của VPN của bạn).

**Không tìm thấy 
`Hermes
` sau khi chạy trình cài đặt.**
Trình cài đặt thêm 

~/.local/bin
` vào PATH của shell thông qua 

~/.bashrc

. Bạn cần 
`source ~/.bashrc
` (hoặc mở một terminal mới) để nó có hiệu lực trong phiên hiện tại.

**Bộ bảo vệ Windows hoạt động chậm trên các tệp WSL.**
Bộ bảo vệ quét các tệp qua cầu 9P khi được truy cập từ Windows, điều này làm tăng độ chậm của truy cập xuyên ranh giới kiểu 

/mnt/c

. Nếu bạn chỉ chạm vào các tệp WSL từ bên trong WSL thì điều này không thành vấn đề. Nếu bạn thường xuyên sử dụng các công cụ Windows chống lại 

\\wsl$\...

, hãy cân nhắc loại trừ đường dẫn phân phối WSL khỏi quá trình quét theo thời gian thực.

**Hết đĩa.**
WSL2 lưu trữ đĩa VM của nó dưới dạng VHDX thưa thớt trong 

%LOCALAPPDATA%\Packages\...

. Nó phát triển nhưng không tự động thu nhỏ khi bạn xóa tập tin. Để lấy lại dung lượng: 
`wsl --shutdown

, sau đó chạy 
`Optimize-VHD -Path <path-to-ext4.vhdx -Mode Full
` từ Quản trị viên PowerShell (yêu cầu các công cụ Hyper-V) — hoặc đường dẫn 
`diskpart
` đơn giản hơn được ghi lại trên tài liệu WSL.

## Đi đâu tiếp theo
- **[Installation](/docs/getting-started/installation)** — các bước cài đặt thực tế (Linux/WSL2/Termux đều sử dụng cùng một trình cài đặt).

- **[Integrations → Providers → WSL2 Networking](/docs/integrations/providers#wsl2-networking-Windows-users)** — mạng chuyên sâu dành cho máy chủ mô hình cục bộ.
- **[MCP guide → WSL → Windows Chrome](/docs/guides/use-MCP-with-Hermes#wsl2-bridge-Hermes-in-wsl-to-Windows-chrome)** — kiểm soát Windows Chrome đã đăng nhập của bạn từ Hermes trong WSL.
- **[Tool Gateway](/docs/user-guide/features/tool-gateway)** và **[Web Dashboard](/docs/user-guide/features/web-dashboard)** — các dịch vụ lâu dài mà bạn thường muốn cung cấp từ WSL cho phần còn lại của mạng.