diff --git a/infra/compute/hosts/zlambda.md b/infra/compute/hosts/zlambda.md
index fe6bc61..6490ee5 100644
--- a/infra/compute/hosts/zlambda.md
+++ b/infra/compute/hosts/zlambda.md
@@ -58,13 +58,18 @@ NixOS 베이스 호스트 (도쿄, Linode nano). 이전 `sandbox-tokyo` 장비
 - 인증: sftp 컨테이너 자체 sshd (publickey/password). **chroot 미사용**(`ChrootDirectory none`), `Match User inbest` → `ForceCommand internal-sftp`, home `/data`(소유 `inbest:sftponly`), 고객 사이트별 디렉토리(in-best-com, leewell-com 등). 비밀번호 yescrypt(`$y$`). 계정 시크릿은 Vault. 2026-06-11 검증: password/키 인증·10MB 업다운로드 정상(40/40)
 - ⚠️ 2201이 2026-06-10 인터넷 개방됨 → sshd 무차별 대입 스캔 노출. inbest 계정 약한 비밀번호 → 키 전용 전환 또는 fail2ban 검토 권장
 
-#### 2026-06-11 장애 근본원인: OpenSSH PerSourcePenalties (★ 진짜 원인)
+#### 2026-06-11 inbest SFTP "전송만 안 됨" 장애 — 실제 원인은 클라이언트(FileZilla)
 
-- **증상**: FileZilla로 접속·폴더 목록은 되는데 파일 업로드/다운로드만 실패. 진입점 `139.162.71.52:2201`.
-- **근본원인**: 백엔드 sshd(OpenSSH 10.0p2)의 `PerSourcePenalties`(10.0 기본 활성, `authfail:5 noauth:1 ... netblocksize 32`). 릴레이(nginx)→tailscale→**OpenWrt subnet-router SNAT** 경유라 모든 외부 클라이언트가 **단일 source `192.168.9.1`**로 보임. 스캐너/오타/FileZilla 재시도 중 한 건이라도 인증 실패하면 공유 source 전체에 페널티 누적 → 그 source의 **새 연결을 드롭**. 이미 인증된 탐색 연결(폴더 목록)은 유지되고, FileZilla가 전송용으로 **새로 여는 연결만 드롭** → "목록은 보이나 전송 실패". (socat/nginx 릴레이는 무관 — socat·nginx 둘 다 전송 자체는 정상이었음)
-- **수정**: 컨테이너 sshd 드롭인 `/etc/ssh/sshd_config.d/00-relay-penalty-exempt.conf` → `PerSourcePenaltyExemptList 192.168.9.1` + `systemctl restart ssh`(누적 페널티 메모리 초기화). 릴레이 뒤에선 per-source 페널티가 무의미·유해하므로 면제.
-- **검증(2026-06-11)**: 인증 실패 8연발 직후 정상연결 5/5, 동시 키 전송 8/8(5MB 업다운 체크섬 일치), password 인증 10MB 업다운 3/3.
-- **잔여 권고**: 면제로 릴레이 경유 brute-force 방어가 사라짐 → 실 방어는 zlambda nginx `limit_conn`/fail2ban 또는 Linode 방화벽 소스 제한으로. inbest 약한 비밀번호 키 전용 전환 권장.
+- **증상**: FileZilla로 접속·디렉토리 이동은 되는데 파일 업로드/다운로드만 실패. 진입점 `139.162.71.52:2201`. (원격지원으로 "디렉토리는 다 돌아다님, 전송만 실패" 확인)
+- **★ 실제 근본원인 (클라이언트)**: 고객 FileZilla가 **탐색 연결은 올바른 비번으로 인증**해 살려두고, 전송용으로 **새로 여는 연결에는 틀린 저장 비밀번호**를 보냄 → 백엔드에 `Failed password` / `unix_chkpwd: password check failed`가 전송 시점마다 찍힘(약 7~8초 간격 = FileZilla 재시도). 그래서 "이동은 되는데 전송만 실패".
+- **해결**: 고객 FileZilla 사이트관리자 → 로그온 유형 **Normal** + 저장 비밀번호 `inbest1004` 재입력(복붙 금지) + 전송설정 탭 **"동시 연결 수 제한 = 1"**(전송이 인증된 단일 연결을 재사용 → 틀린 비번 가는 2번째 연결 제거). 적용 후 백엔드 로그 전부 `Accepted password`로 전환, 전송 정상.
+- **서버는 무죄**: 서버·릴레이·계정 모두 정상이었음. 검증 — kappa 로컬·사용자 맥 양쪽에서 password/키 인증·순차/동시(9/9, 8/8) 10MB 업다운 전부 성공. `inbest1004`는 유효(shadow yescrypt 해시 일치).
+
+##### 진단 중 적용한 서버측 개선 (원인 아님, 유지)
+
+- **socat → nginx stream 릴레이 교체** (위 본문). socat·nginx 둘 다 전송 자체는 정상이었으나 nginx로 일원화.
+- **PerSourcePenalties 면제**: `/etc/ssh/sshd_config.d/00-relay-penalty-exempt.conf` → `PerSourcePenaltyExemptList 192.168.9.1` + `systemctl restart ssh`. 백엔드 sshd(OpenSSH 10.0, penalties 기본 활성)는 릴레이→OpenWrt SNAT로 **모든 외부 클라이언트가 단일 source `192.168.9.1`**로 보여, 한 클라이언트(스캐너 등)의 인증 실패가 공유 source 전체를 페널티→정상 고객 새 연결 드롭 위험. 릴레이 뒤 per-source 페널티는 무의미·유해하므로 면제. (이번 장애의 직접 원인은 아니었지만 잠재 collateral 차단 예방)
+- **잔여 권고**: 면제로 릴레이 경유 brute-force 방어 공백 → zlambda nginx `limit_conn`/fail2ban 또는 Linode 방화벽 소스 제한. inbest 약한 비밀번호 키 전용 전환 권장.
 - **Linode Cloud Firewall**: zlambda는 공인 IP에서 **22만 기본 개방**, 나머지(80/443/8443/9999)는 차단. 2201은 2026-06-10 인바운드 허용 추가(zlambda 소속 Linode 계정은 Vault `cloud/linode`(ironclad/apisix-osaka)와 **다른 계정** — 토큰 미보유, 방화벽은 사용자가 대시보드에서 관리)
 - [[../../services/sftpgo|SFTPGo]] / [[../../network/sshpiper|sshpiper]]와 역할 구분 (이건 단순 TCP relay)