이 글의 목차
Telegram이 OpenClash로 전혀 유입되지 않는지 확인
이 글은 매우 구체적인 우회 문제를 다룹니다. 같은 기기의 웹페이지는 OpenClash를 통해 열리지만 Telegram은 연결되지 않고, Telegram을 새로 고쳐도 Dashboard에는 관련 연결이 전혀 나타나지 않는 반면 WAN에서는 직접 외부로 나가는 트래픽이 보이는 경우입니다.
공식 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의 트래픽 인수가 적용되지 않음 | 실행 상태, 모드와 방화벽 로드 확인 |
설정을 저장하고 라우터 관리 경로 유지
방화벽 관련 옵션을 바꾸기 전에 OpenClash 설정과 현재 구성을 내보내고 실행 모드, 플러그인 버전, 코어 버전, 소스 트래픽 접근 제어 페이지를 기록하세요. 원격으로 유지보수할 때는 별도의 LAN 관리 경로도 확보해야 합니다.
이번 점검에서는 빈 항목 하나만 처리하며 구독 업데이트, 코어 전환, DNS 변경 또는 규칙 재작성은 함께 하지 않습니다. 한 번에 하나만 바꿔야 재시작 전후의 Dashboard와 WAN 경로로 결과를 판단할 수 있습니다.
롤백 경로 준비
현재 설정 내보내기
플러그인 설정과 현재 구성을 라우터 외부에 저장해 유효한 접근 제어를 실수로 삭제해도 복원할 수 있게 합니다.
빈 항목 페이지 캡처
항목 이름, 활성화 상태, 프로토콜, 주소 체계, 동작과 모든 일치 조건을 기록합니다.
로컬 관리 경로 확인
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보다 앞에 있어 연결이 조기에 반환됩니다.
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 재시작
OpenClash 유지관리자는 이 issue에 대해 소스 트래픽 접근 제어를 삭제하라고 안내했습니다. 일반 사용자는 LuCI 화면에서 빈 항목임을 확인한 뒤 삭제하고 저장 및 적용한 다음 OpenClash를 재시작해 nftables 규칙을 다시 생성하는 방식을 우선해야 합니다.
화면에서 당장 삭제할 수 없다면 보고자가 검증한 것처럼 해당 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와 로그의 근거에 따라 다음 진단 방향 결정