자주 걸리는 지점
두 개의 127.0.0.1. 문서대로 루프백에 바인드해도 스마트폰 webhook이 안 들어옵니다. WSL2 안의 루프백은 경량 VM 쪽이며 Windows·라우터 인터페이스와 같지 않습니다.
unit이 안 돈다. systemd가 PID 1이 되기 전에 복사한 unit은 장식입니다. 상주 글과 모순됩니다.
절전·VPN. 장시간 연결이 끊깁니다. 채널 글처럼 doctor와 로그를 짝지으세요.
TLS 종료. Windows에서 TLS를 끊고 WSL로 넘기면 WebSocket·allowedOrigins에서 어긋납니다. 프록시 글과 대조하세요.
여러 Node. ExecStart가 옛 경로를 가리킬 수 있습니다. 설치·롤백에서 절대 경로를 확인하세요.
WSL2 네임스페이스
배포판은 자체 라우팅을 가집니다. 미러 모드가 일부를 완화해도 콜백 URL·인증서·방화벽 다이어그램은 필요합니다.
아웃바운드 NAT는 잘 되므로 “나가기만 되고 들어오기 불안”은 인바운드 경로 미완성을 의심합니다.
LAN에서 도달하려면 WSL 0.0.0.0만으로 부족하고 Windows portproxy와 FW가 필요합니다. 더 안전한 것은 루프백+리버스 프록시이거나 SFTPMAC 호스팅 원격 Mac에 엣지를 두는 것입니다.
DNS 스플릿은 OAuth를 간헐적으로 깨뜨립니다. Windows와 WSL에서 각각 확인하세요. 시각 오차도 단기 토큰에 영향을 줍니다.
systemd를 실제로
wsl.conf에서 systemd=true 후 wsl --shutdown으로 재시작하고 PID 1을 확인합니다.
이후 서버와 같이 unit을 정리하고 status → gateway → doctor → logs로 증거를 남깁니다.
사용자·비밀 경로를 문서화하고 /mnt/c 환경 파일은 권한·CRLF를 주의합니다.
정책상 systemd가 불가하면 백오프 있는 감독이 필요합니다.
저널 지속성과 디스크 한도를 확인하고 업그레이드 전후 doctor 출력을 보관합니다.
결정 표
| 패턴 | 이점 | 리스크 | 맞는 경우 |
|---|---|---|---|
| WSL 루프백만 | 노출 최소 | 외부 직접 테스트 불가 | 로컬 CLI |
| 전 인터페이스+portproxy | LAN 경로 명확 | 과노출 쉬움 | 집 실험 |
| Windows TLS 종료 | 인증서 집중 | WebSocket 실수 | 유사 운영 데스크 |
| SSH 터널 | 가정에 공인 리스너 불필요 | 불안정 | 개인 실험 |
| 호스팅 원격 Mac | 전원·네트워크 단순 | 벤더 평가 | 가동률 중시 |
| Docker Desktop | 재현성 | NAT 증가 | Compose 표준화 |
환경마다 주 경로는 하나만 문서화하세요. 반쯤 루프백 반쯤 LAN이 가장 비쌉니다.
명령 사다리
# 1) systemd (예; 배포판 문서 따름)
# sudo tee /etc/wsl.conf <<'EOF'
# [boot]
# systemd=true
# EOF
# Windows: wsl --shutdown
# 2) init·unit
# ps -p 1 -o comm=
# systemctl status openclaw-gateway.service
# 3) WSL 리스닝
# ss -lntp | head
# 4) portproxy 예 (관리자 PowerShell)
# netsh interface portproxy add v4tov4 listenport=8443 listenaddress=0.0.0.0 connectport=8443 connectaddress=<WSL-IP>
# 5) 진단 (하위 명령은 버전에 맞출 것)
# openclaw status
# openclaw gateway status
# openclaw doctor
# openclaw logs --follow
티켓에는 다섯 출력을 함께 첨부하세요. 스크린샷만으로는 부족합니다.
읽는 순서
설치 → 상주 → 채널 → 프록시. 변경은 롤백과 병행합니다.
계층 doctor: systemd·포워딩·인증서·VPN을 바꿀 때마다 재실행하고, doctor 통과에도 침묵이면 채널 로그로 갑니다.
Slack이 회사 프록시를 타면 WSL로 넘길 변수를 문서화하세요.
스테이징과 운영의 오리진을 맞춰 allowedOrigins를 운영에서 처음 터뜨리지 마세요.
FAQ와 SFTPMAC 호스팅 원격 Mac
미러 네트워크가 만능인가요
아닙니다. 리스닝·FW·콜백 URL을 명시하고 외부 클라이언트로 검증하세요.
doctor는 되는데 절전 후 조용함
절전 시각과 로그를 대조하고 필요 시 게이트웨이를 재시작하세요.
운영 게이트웨이를 노트북에 둘까요
보통은 피합니다. 상시 전원 장비나 호스팅으로 옮기세요.
WSL 개발만 하는데 Mac이 필요한가요
역할을 나눌 수 있습니다. 개발은 WSL, 게이트웨이는 SFTPMAC 호스팅 원격 Mac에 두면 Windows 포워딩·절전 리스크를 줄이고 SSH·SFTP 운영과 맞춥니다.
요약: WSL2는 네임스페이스와 선택적 systemd의 조합입니다. localhost·포워딩·TLS 종료를 이름 붙이고 doctor를 계층적으로 실행해 채널 로그와 맞추세요.
한계: Windows 빌드·기업 VPN 조합을 모두 담을 수 없습니다. 통합 비용이 크면 게이트웨이를 호스팅 macOS로 옮기고 데스크는 WSL을 유지할 수 있습니다.
WSL 포트·절전 부담을 줄이려면 SFTPMAC 안정 원격 Mac을 검토해 보세요.