이 글의 목차
웹페이지는 프록시를 사용하는데 채팅 앱만 연결되지 않는다고 도메인 규칙이 부족한 것은 아닙니다. 대시보드에 연결이 없다면 노드를 바꾸기 전에 트래픽이 프록시에 도착하는지 확인하세요. 빈 접근 제어 항목 때문에 트래픽이 프록시 처리를 건너뛸 수 있으므로 구성과 실행 규칙이 모두 이 조건에 맞을 때만 해당 빈 항목을 처리합니다.
웹페이지는 프록시를 사용하지만 Telegram은 직접 연결
같은 기기와 네트워크를 유지하고 Telegram이 연결을 재시도할 때 Dashboard와 라우터 WAN(외부 네트워크) 기록을 확인하세요. 웹 트래픽은 OpenClash를 통과하지만 Telegram 기록은 없고 직접 외부로 나갈 때 아래의 빈 접근 제어를 점검합니다. 앱이 연결되지 않는다는 사실만으로 원인을 단정할 수는 없습니다.
공식 issue #5283에는 ImmortalWrt 25.12.1의 fw4/nftables 환경에서 나타난 이 현상이 기록되어 있습니다. 보고된 빈 lan_ac_traffic 항목은 RETURN(중간에 반환) 규칙을 생성했고, 대부분의 TCP와 UDP 트래픽이 Mihomo에 도달하기 전에 반환되었습니다.
Dashboard에서 Telegram 연결과 적용 규칙, 정책 그룹, 출구 노드가 보인다면 트래픽은 이미 코어에 들어온 상태입니다. 이때는 노드, 규칙, UDP 또는 DNS를 확인해야 하며 소스 접근 제어를 계속 삭제하면 안 됩니다.
연결 기록으로 트래픽이 멈추는 위치 확인
| 관찰 결과 | 가능성이 높은 단계 | 다음 단계 |
|---|---|---|
| 웹은 정상이나 Telegram 기록이 없고 WAN으로 직접 나감 | 투명 프록시 전에 RETURN됨 | 비어 있는 소스 트래픽 접근 제어 확인 |
| Telegram 기록은 있지만 DIRECT에 일치 | 규칙 선택 | 해당 연결에 적용된 규칙과 정책 그룹 확인 |
| Telegram 기록은 있지만 노드 오류 발생 | 프록시를 통한 외부 연결 | 노드를 고정한 뒤 프로토콜, UDP와 네트워크 확인 |
| 어떤 앱도 연결 기록이 없음 | OpenClash로 트래픽이 전달되지 않음 | 실행 상태, 모드와 방화벽 로드 확인 |
설정을 저장하고 라우터 관리 경로 유지
이번 점검에서는 빈 항목 하나만 처리하며 구독 업데이트, 코어 전환, DNS 변경 또는 규칙 재작성은 함께 하지 않습니다. 한 번에 하나만 바꿔야 재시작 전후의 Dashboard와 WAN 경로로 결과를 판단할 수 있습니다.
복구에 필요한 설정과 관리 접속 경로 확보하기
현재 설정 내보내기
OpenClash 설정과 현재 구성을 내보내 라우터 외부에 저장하고, 실행 모드와 플러그인·코어 버전을 기록하세요. 유효한 접근 제어를 실수로 삭제했을 때 복원할 수 있어야 합니다. 원격 작업 중에는 별도의 LAN 관리 접속 경로를 유지하세요.
빈 항목 페이지 캡처
항목 이름, 활성화 상태, 프로토콜, 주소 체계, 동작과 모든 일치 조건을 기록합니다.
로컬 관리 경로 확인
LAN에서 라우터 관리 페이지를 여세요. 원격 접속만 가능한 경우 방화벽과 OpenClash를 바로 재시작하면 안 됩니다.
테스트 기기 고정
먼저 문제가 재현되던 기기 한 대에서만 Telegram을 테스트하고 다른 단말의 설정은 당분간 바꾸지 않습니다.
비어 있는 소스 트래픽 접근 제어 항목 확인
OpenClash의 출발지 트래픽 접근 제어 화면을 여세요. 활성화되어 있고 동작이 반환 또는 프록시 우회이지만 출발지 주소, 목적지 주소, 포트, 인터페이스 같은 일치 조건이 없는 항목을 찾으세요. 아래 규칙 점검은 이러한 빈 항목을 대상으로 합니다.
항목이 특정 기기, 서브넷 또는 포트를 명확히 한정한다면 실제 직접 연결 요구를 담당할 수 있습니다. 이름이 같다는 이유만으로 삭제하지 말고 먼저 조건과 예상 용도를 기록한 뒤 유지 여부를 판단하세요.
uci show openclash | grep lan_ac_trafficopenclash.@lan_ac_traffic[0]=lan_ac_traffic
openclash.@lan_ac_traffic[0].enabled='1'
openclash.@lan_ac_traffic[0].proto='both'
openclash.@lan_ac_traffic[0].family='both'
openclash.@lan_ac_traffic[0].target='return'빈 항목 판정 조건
- section 유형이 lan_ac_traffic이고 현재 enabled 값이 1임
- 동작이 return이며 프로토콜과 주소 체계가 TCP, UDP, IPv4 및 IPv6를 포함할 수 있음
- 소스 IP, 대상 IP, 포트, 인터페이스 또는 그 밖의 실제 일치 조건이 없음
- 특정 기기를 위해 남겨 둔 명시적인 직접 연결 정책이 아님
거의 모든 트래픽에 적용되는 RETURN 규칙 확인
구성에 빈 항목이 있다면 실제로 런타임 규칙을 생성했는지도 확인해야 합니다. 공식 보고서의 규칙은 0부터 65535까지의 소스 포트와 일치하고 Fake-IP 주소 대역을 제외합니다. redirect 또는 TPROXY보다 앞에 있어 연결이 조기에 반환됩니다.
아래 nft 명령은 라우터 터미널에서 fw4의 OpenClash 체인을 변경 없이 확인하는 용도입니다. lan_ac_traffic 주석이 있고 거의 모든 TCP 또는 UDP에 적용되는 RETURN을 찾으세요. handle은 실행 중인 규칙의 번호이며 다시 생성할 때 바뀔 수 있으므로 issue의 803, 805를 그대로 복사해 삭제하지 마세요.
nft -a list chain inet fw4 openclash
nft -a list chain inet fw4 openclash_mangle거의 모든 트래픽을 포괄하는 lan_ac_traffic RETURN이 나타남
출력을 보존하고 화면으로 돌아가 해당 빈 항목을 삭제하며 임시 handle에 직접 의존하지 않습니다.
명확한 소스 또는 대상 조건이 있는 RETURN만 존재
빈 항목에서 생성된 전체 적용 규칙이 아니므로 먼저 해당 정책의 실제 용도를 확인합니다.
lan_ac_traffic 규칙이 없음
이 글의 작업을 중단하고 트래픽이 OpenClash에 들어오는지, 규칙이 적용되는지, 노드나 DNS에 문제가 있는지 확인하세요.
기기에 nft 명령이 없거나 체인 이름이 다름
체인 이름을 추측하거나 규칙을 삭제하지 말고 버전과 방화벽 정보를 저장한 뒤 해당 펌웨어 문서에 따라 점검합니다.
- Telegram이 연결 시작단말 요청은 원래 OpenClash 투명 프록시로 들어가야 함
- 빈 lan_ac_traffic 항목소스, 대상, 포트 또는 인터페이스 조건이 없음
- 거의 모든 트래픽에 적용되는 RETURN 규칙redirect 또는 TPROXY보다 앞에서 조기 반환
- WAN으로 직접 외부 연결트래픽이 Mihomo를 우회해 Dashboard에 기록이 남지 않음
빈 항목을 삭제하고 OpenClash를 다시 시작한 뒤에는 새 방화벽 규칙에 이 범위가 지나치게 넓은 RETURN이 없어야 합니다. Telegram 연결은 Mihomo로 전달되고 Dashboard에 표시되어야 합니다.
빈 항목을 삭제하고 OpenClash 재시작
화면에서 당장 삭제할 수 없다면 보고자가 검증한 것처럼 해당 section을 비활성화해도 복구할 수 있습니다. 아래 인덱스는 uci show에서 빈 항목이 정확히 0번째로 표시되는 기기에만 적용됩니다. 인덱스가 다르면 실제 값으로 바꿔야 합니다.
최소 범위로 처리
항목이 비어 있는지 다시 확인
소스, 대상, 포트 또는 인터페이스 조건이 전혀 없고 업무상 직접 연결에 의존할 필요도 없는지 확인합니다.
LuCI에서 삭제하는 방식을 우선 사용
해당 빈 항목을 삭제하고 저장 및 적용하되 다른 접근 제어나 트래픽 분기 옵션은 바꾸지 않습니다.
OpenClash 재시작
Dashboard만 새로 고치지 말고 구성 검사, 코어와 방화벽 규칙이 모두 다시 로드될 때까지 기다립니다.
nftables 다시 확인
기존의 전체 적용 lan_ac_traffic RETURN이 사라졌는지 확인한 뒤 Telegram 테스트를 시작합니다.
uci set openclash.@lan_ac_traffic[0].enabled='0'
uci commit openclash
/etc/init.d/openclash restartTelegram이 Mihomo로 유입되는지 확인
같은 테스트 기기에서 Telegram을 다시 열면서 OpenClash Dashboard를 관찰합니다. 연결이 목록에 나타나기 시작하고 적용 규칙, 정책 그룹과 실제 외부 경로가 표시되어야 합니다. 앱이 다시 작동하는 것만으로 더 이상 직접 연결되지 않는다고 판단하기에는 부족합니다.
WAN 경로와 일반 웹페이지도 다시 확인합니다. 목표는 Telegram이 더 이상 우회하지 않고 기존 웹페이지도 정상적으로 열리며 다른 기기에 필요했던 명시적 직접 연결 정책이 실수로 삭제되지 않은 상태입니다. 재시작 직후에만 잠시 복구된다면 구성 동기화가 빈 항목을 다시 쓰는지 확인하세요.
수정 완료 기준
- 재시작 후 조건 없는 lan_ac_traffic RETURN이 더 이상 나타나지 않음
- Telegram 데스크톱 또는 모바일 앱에서 실제 연결을 한 번 완료할 수 있음
- Dashboard에서 해당 연결, 규칙, 정책 그룹과 외부 경로를 확인할 수 있음
- WAN에서 해당 트래픽이 Mihomo를 우회해 직접 나가는 모습이 더 이상 보이지 않음
- 일반 웹페이지, DNS와 다른 단말도 기존 계획대로 작동함
검증 실패 시 확인할 부분
| 실패 양상 | 설명 | 처리 방향 |
|---|---|---|
| Telegram이 여전히 Dashboard에 기록되지 않음 | 프록시로 들어오기 전에 여전히 우회됨 | 다른 RETURN, 기기 접근 제어와 투명 프록시 진입점 확인 |
| 기록은 나타나지만 연결에 실패 | 트래픽이 다시 프록시로 들어옴 | 노드, 규칙, UDP와 대상 네트워크 확인 |
| 재시작 후 항목이 다시 나타남 | 구성 소스에서 계속 항목을 작성함 | 백업 복원, 동기화 스크립트 또는 화면에 남은 설정 확인 |
| 다른 기기의 기존 직접 연결이 작동하지 않음 | 유효한 정책을 삭제함 | 백업을 복원하고 명확한 조건이 있는 항목을 다시 생성 |
빈 항목이 없거나 유효한 규칙을 잘못 삭제했다면 각각 어떻게 처리하나요?
삭제 후 기존 직접 연결 기기에 영향이 생겼다면 즉시 설정 백업을 복원하고 OpenClash를 재시작한 뒤 직접 연결이 필요한 소스, 대상 또는 포트를 명확한 조건으로 작성합니다. 설명 가능한 여러 접근 제어 대신 조건 없는 return 항목 하나를 사용하면 안 됩니다.
빈 항목이나 전체 트래픽에 적용되는 RETURN이 없거나 Telegram이 이미 Dashboard에 표시된다면, 빈 항목 때문에 중간에 반환되는 문제는 배제된 것입니다. 이후에는 연결 기록을 바탕으로 규칙, 노드, UDP, DNS 또는 앱 자체의 네트워크 동작을 살펴보고 nftables 수정은 중단하세요.
이 issue는 게시 시점에도 열려 있었으며, 공식 기록에서 수정이 포함된 안정 버전도 확인되지 않았습니다. 빈 설정 삭제는 유지 관리자가 제안한 조치입니다. 특정 버전으로 업데이트하면 자동으로 해결된다고 단정할 수 없습니다.
롤백 후 다시 확인
- 라우터 LAN 관리 경로와 일반 네트워크가 복구됨
- 유효한 소스 접근 제어가 명확한 조건에 따라 다시 생성됨
- OpenClash 재시작 후 구성 검사와 방화벽 로드에 성공함
- Dashboard와 로그의 근거에 따라 다음 진단 방향 결정