# Container bị đánh dấu unhealthy nhưng dịch vụ vẫn chạy

> Một container báo cáo unhealthy trong khi nó phục vụ lưu lượng vẫn tốt — một âm tính giả của health-probe.

## Triệu chứng

Một container — thường là frontend — hiện unhealthy trong `docker ps`, nhưng ứng dụng vẫn tới được và phục vụ bình thường trong trình duyệt. Probe tình trạng ghi log "connection refused" dù dịch vụ vẫn lên.

Nguyên nhân: probe nhắm tới `localhost`, vốn phân giải thành **cả** IPv6 (`::1`) và IPv4 (`127.0.0.1`). Công cụ probe thử IPv6 trước, nhưng máy chủ bên trong container chỉ lắng nghe trên IPv4 — nên lần thử IPv6 bị từ chối và probe báo cáo sai rằng container đã sập.

## Xác nhận

Kiểm tra tình trạng được báo cáo của container so với khả năng tới được thực tế của nó:

```bash
docker ps --format '{{.Names}}\t{{.Status}}' | grep aiboard
```

Nếu một container đọc là `(unhealthy)` nhưng ứng dụng phản hồi khi bạn truy cập trực tiếp trên IPv4, đó là âm tính giả này:

```bash
# từ bên trong container — IPv4 một cách tường minh
docker compose -f docker-compose.release.yml exec frontend \
  sh -c 'wget -qO- http://127.0.0.1:8080/ >/dev/null && echo "IPv4 OK"'
```

Nếu `IPv4 OK` in ra, dịch vụ khỏe mạnh và chỉ có probe là sai.

## Sửa

Các image hiện tại đã probe IPv4 một cách tường minh, nên một hộp khỏe mạnh sẽ không gặp điều này. Nếu bạn vẫn thấy nó trên một image cũ:

1. **Xác nhận dịch vụ thực sự đang phục vụ** (kiểm tra IPv4 ở trên in `IPv4 OK`). Nếu có, không cần hành động ứng dụng nào — container vẫn khỏe mạnh.

2. **Cập nhật lên một image phát hành hiện tại**, nơi health probe nhắm tới `127.0.0.1` trực tiếp và âm tính giả biến mất:

   ```bash
   docker compose -f docker-compose.release.yml up -d
   ```

3. **Kiểm tra lại** trạng thái được xóa:

   ```bash
   docker ps --format '{{.Names}}\t{{.Status}}' | grep aiboard
   ```

Vì probe mới là cái đã sai (không phải dịch vụ), một container phụ thuộc đang chờ
tình trạng của container này có thể bị giữ lại dù mọi thứ thực sự đang phục vụ. Hãy sửa
probe thay vì tắt healthcheck.

## Phòng ngừa

- **Probe đúng địa chỉ mà máy chủ thực sự bind.** Health probe nên nhắm tới `127.0.0.1` một cách tường minh khi máy chủ chỉ lắng nghe trên IPv4, để việc phân giải tên không thể gửi probe tới một địa chỉ IPv6 chưa được bind.
- **Phân biệt lỗi probe với lỗi dịch vụ.** Trước khi phản ứng với một trạng thái `unhealthy`, hãy xác nhận bằng một yêu cầu IPv4 trực tiếp. Một ứng dụng xanh sau một probe đỏ là một lỗi probe, không phải một sự cố ngừng hoạt động.

## Liên quan

- [Khả năng quan sát & Cảnh báo](/operate/monitoring/) — diễn giải các tín hiệu tình trạng và trạng thái.
