먼저 토폴로지 결정하기: 메인 라우터에 배포할까, 바이패스 라우터에 배포할까
Clash Meta(현재는 보통 mihomo라고 부르는 코어)를 가정용 네트워크에 배치하는 일은 컴퓨터에서 데스크톱 클라이언트를 실행하는 것과 크게 다릅니다. 데스크톱 클라이언트는 일반적으로 로컬 컴퓨터의 트래픽만 처리하지만, 라우터 구성은 포워딩, 정책 라우팅, DNS, IPv4와 IPv6를 함께 다루면서 프록시 프로그램의 상위 연결이 다시 프록시로 들어가지 않도록 해야 합니다. 배포 전에 데이터 경로를 명확히 그려 보는 것이 플러그인을 바로 설치하는 것보다 중요합니다.
구성 1: 메인 라우터에서 Clash 코어 실행
메인 라우터가 직접 인터넷 연결, DHCP, NAT, 방화벽과 투명 프록시를 담당합니다. 단말의 기본 게이트웨이는 자연스럽게 이 장치를 가리키므로 기기별로 네트워크 설정을 바꿀 필요가 없습니다. OpenWrt를 예로 들면 라우터 LAN 주소는 192.168.10.1, DHCP 주소 풀은 192.168.10.100–192.168.10.249로 설정할 수 있으며, 클라이언트 게이트웨이와 DNS는 DHCP를 통해 자동으로 192.168.10.1이 배포됩니다.
- 장점: 트래픽 진입점이 하나로 통합되어 단말이 연결되면 바로 규칙을 적용할 수 있고, 게스트 네트워크와 독립 VLAN도 각각 제어할 수 있습니다.
- 제한 사항: 프록시, 인터넷 연결, 무선 기능과 NAT가 한 장치의 CPU와 메모리를 공유하므로 설정 오류가 전체 LAN에 영향을 줄 수 있습니다.
- 적합한 환경: 성능이 충분한 x86 OpenWrt, 소형 소프트웨어 라우터 또는 쿼드코어 ARM64 라우터 장치.
구성 2: 바이패스 라우터에서 Clash 코어 실행
바이패스 라우터와 메인 라우터는 같은 LAN에 연결됩니다. 메인 라우터가 192.168.10.1, 바이패스 라우터가 192.168.10.2라고 하면 바이패스 라우터 자체의 기본 게이트웨이는 여전히 192.168.10.1을 가리킵니다. 프록시가 필요한 단말은 기본 게이트웨이와 DNS를 192.168.10.2로 설정합니다. 데이터는 먼저 바이패스 라우터로 들어가 투명 프록시의 판단을 거친 뒤 메인 라우터를 통해 인터넷에 접속합니다.
이러한 단일 NIC 바이패스 라우터는 이더넷 인터페이스가 하나뿐이어서 인바운드와 아웃바운드 트래픽이 같은 네트워크 카드로 통과합니다. 기가비트 네트워크에서 인터넷 트래픽을 한 번 전달하면 해당 인터페이스에서 양방향 송수신이 발생하지만, 이것만으로 속도가 바로 절반으로 떨어지는 것은 아닙니다. 실제 병목은 암호화 처리량, 규칙 매칭, USB 네트워크 카드 품질과 메인 라우터로 돌아가는 경로에서 더 자주 발생합니다.
| 비교 항목 | 메인 라우터 실행 | 바이패스 라우터 실행 |
|---|---|---|
| 단말 변경 사항 | 일반적으로 필요 없음 | 게이트웨이, DNS 또는 DHCP 배포 설정 변경 필요 |
| 장애 영향 | 전체 네트워크의 외부 연결에 영향을 줄 수 있음 | 게이트웨이를 메인 라우터로 되돌리면 복구 가능 |
| 하드웨어 선택 | 라우터 장치 사양의 제약을 받음 | 라즈베리 파이, 미니 PC 또는 구형 컴퓨터 사용 가능 |
| 네트워크 복잡도 | 포워딩 경로가 단순함 | 리턴 경로, DHCP와 IP 포워딩 확인 필요 |
OpenWrt 플러그인과 라즈베리 파이 독립 실행 구성 선택하기
OpenWrt 플러그인 구성은 코어, 설정 구독, 규칙 업데이트, 방화벽 연동과 실행 로그를 하나의 관리 화면에 모읍니다. 라즈베리 파이 독립 실행 구성은 보통 mihomo 바이너리를 직접 실행한 뒤 systemd, nftables와 dnsmasq로 전체 경로를 구성합니다. 두 방식의 핵심 기능은 비슷하며, 주된 차이는 유지 관리 방식과 장애를 좁혀 가는 단위에 있습니다.
OpenWrt 플러그인 구성
OpenWrt 24.10 계열과 OpenClash 관리 화면을 예로 들면 일반적인 작업 경로는 「서비스」→「OpenClash」→「설정 파일 구독」입니다. 구독 주소와 업데이트 주기를 설정한 다음 「서비스」→「OpenClash」→「플러그인 설정」에서 실행 모드, DNS 가로채기 방식과 접근 제어를 선택합니다. 플러그인 버전에 따라 메뉴 이름은 조금 다를 수 있지만 설정 흐름은 대체로 같습니다.
- 장치 아키텍처가
x86_64,aarch64_cortex-a53또는mipsel_24kc인지 확인합니다. 코어 파일은 아키텍처와 일치해야 합니다. - 영구 저장 공간을 확보합니다. 규칙 세트, Geo 데이터, 로그와 여러 설정 파일이 80MB 이상을 차지할 수 있으므로 플래시가 16MB뿐인 구형 장치는 많은 데이터를 장기간 보관하기에 적합하지 않습니다.
- 먼저 규칙 모드로 시작한 뒤 TCP, UDP와 DNS를 각각 테스트합니다. 실험적인 옵션을 처음부터 모두 활성화하지 마세요.
- 「실행 상태」 또는 「디버그 로그」에서 설정 파싱이 완료되었는지, 투명 프록시 규칙이 정상적으로 기록되었는지, DNS 수신 포트가 충돌하지 않는지 확인합니다.
플러그인은 LuCI를 통해 구독과 접근 제어를 관리하려는 환경에 적합합니다. OpenWrt를 업그레이드하기 전에는 플러그인 설정, 설정 파일 위치와 사용자 지정 방화벽 규칙을 기록해 두세요. firewall 3과 firewall 4의 하위 구현이 다르기 때문입니다. OpenWrt 22.03 이후의 주류 버전은 firewall4와 nftables를 사용하므로 오래된 문서의 iptables 명령을 그대로 적용할 수 없습니다.
라즈베리 파이 또는 Debian 독립 실행 구성
라즈베리 파이 4B, 라즈베리 파이 5와 Debian 12를 실행하는 ARM64 미니 PC는 모두 바이패스 라우터로 사용할 수 있습니다. 64비트 시스템, 유선 네트워크 포트와 안정적인 전원 공급을 권장합니다. 라즈베리 파이 4B의 내장 기가비트 포트는 일반적인 가정용 네트워크에 적합합니다. USB 3.0 네트워크 카드를 연결한다면 칩셋 드라이버의 안정성을 확인하고 패킷 손실과 재연결 로그를 계속 관찰하세요.
독립 실행 방식에서는 mihomo를 /usr/local/bin/mihomo에 두고 설정 디렉터리를 /etc/mihomo로 지정한 뒤 systemd로 상시 실행할 수 있습니다. 다음 서비스 파일은 필요한 구조를 보여 줍니다. 실제 배포 시에는 전용 사용자를 만들고 해당 사용자에게 설정 디렉터리의 읽기·쓰기 권한도 부여해야 합니다.
[Unit]
Description=mihomo proxy core
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target/etc/systemd/system/mihomo.service로 저장한 뒤 systemctl daemon-reload, systemctl enable --now mihomo, journalctl -u mihomo -n 100을 차례로 실행할 수 있습니다. 투명 프록시 규칙을 작성하기 전에 먼저 mihomo -t -d /etc/mihomo를 실행해 YAML 문법을 확인하세요. 파싱에 실패했는데 부팅 시 방화벽 규칙을 계속 기록하면 트래픽은 리디렉션되지만 코어가 수신 대기하지 않는 상태가 되어 네트워크가 끊길 수 있습니다.
투명 프록시: REDIRECT, TProxy와 TUN의 차이
라우터 배포의 핵심은 HTTP 또는 SOCKS 포트를 하나 여는 것이 아니라, 수동 프록시를 지원하지 않는 TV, 게임기와 IoT 장치의 트래픽도 규칙으로 처리하는 데 있습니다. 흔히 사용하는 방식은 REDIRECT, TProxy와 TUN입니다. 세 방식 모두 LAN 주소, 코어 자체의 연결과 프록시 서버 주소를 올바르게 제외해야 하며, 그렇지 않으면 프록시 루프가 발생하기 쉽습니다.
REDIRECT: 주로 TCP 처리
REDIRECT는 방화벽을 통과하는 TCP 연결을 mihomo의 투명 프록시 포트로 리디렉션합니다. 예를 들어 redir-port: 7892를 사용할 수 있습니다. 구현이 간단해 웹과 애플리케이션의 TCP 트래픽을 먼저 검증하기에 적합합니다. 원래 대상 정보를 유지해야 하는 모든 UDP 상황을 완전히 처리할 수는 없으므로 음성 통화, 게임과 QUIC에는 TProxy 또는 TUN이 필요할 수 있습니다.
TProxy: TCP와 UDP 동시 처리
TProxy는 보통 tproxy-port: 7893과 같은 전용 포트를 사용하며 정책 라우팅, 패킷 마크와 커널 모듈에 의존합니다. 방화벽이 먼저 트래픽에 fwmark를 설정하고, ip rule과 로컬 라우팅 테이블을 통해 데이터를 mihomo로 전달합니다. UDP 투명 프록시, DNS 조회와 일부 실시간 통신은 규칙의 완성도를 더 엄격하게 요구합니다.
- 루프백 주소, 멀티캐스트 주소, LAN 대역과 라우터 관리 주소는 반드시 제외해야 합니다.
- 프록시 노드 서버로 연결되는 트래픽은 상위 네트워크로 직접 나가야 하며 투명 프록시에 다시 들어가서는 안 됩니다.
- mihomo 프로세스 자체의 트래픽을 제외하거나 라우팅 마크로 이미 처리된 패킷을 구분해야 합니다.
- 커널에 TPROXY, 정책 라우팅과 nftables 지원이 포함되어 있는지 확인해야 합니다.
TUN: 가상 네트워크 카드로 IP 트래픽 수신
TUN 모드는 가상 네트워크 인터페이스를 만들고 mihomo가 IP 계층의 트래픽을 수신하도록 합니다. 데스크톱 시스템에서 더 흔하지만 바이패스 라우터에서도 사용할 수 있으며, 이 경우에도 포워딩, 라우팅과 DNS의 협력이 필요합니다. 기본 설정에는 다음과 같은 항목이 포함될 수 있습니다.
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
tun:
enable: true
stack: mixed
auto-route: true
auto-redirect: true
auto-detect-interface: true
strict-route: truemixed-port: 7890은 명시적 HTTP 및 SOCKS 프록시 테스트에 사용합니다. 투명 프록시는 REDIRECT, TProxy 또는 TUN 경로를 사용합니다. 관리 인터페이스는 127.0.0.1:9090에 바인딩해 전체 LAN에 직접 노출되지 않도록 할 수 있습니다. 다른 장치에서 제어 인터페이스에 접근해야 한다면 방화벽으로 관리 대역만 허용하고 컨트롤러 키를 설정하세요.
TUN의 auto-route와 auto-redirect는 수동 규칙을 줄여 주지만, 모든 라우터 환경에서 바로 활성화해도 된다는 뜻은 아닙니다. OpenWrt 플러그인에는 자체 방화벽 관리 로직이 있는 경우가 많아 코어의 자동 라우팅 기록을 추가하면 중복으로 제어될 수 있습니다. 배포할 때 플러그인, 시작 스크립트와 mihomo 중 어느 쪽이 라우팅을 담당할지 명확히 정하고 제어 주체는 하나만 남겨야 합니다.
DNS 가로채기: 누출, 오염과 해석 루프 방지
투명 프록시는 연결을 어떻게 전달할지만 결정하고, DNS는 도메인을 어떤 주소로 먼저 해석할지 결정합니다. 단말이 여전히 메인 라우터나 통신사 DNS에 직접 질의하면 규칙은 대상 IP만 확인하게 되어 도메인 규칙의 적중률이 떨어질 수 있습니다. DNS 요청이 프록시 경로와 직접 연결 경로에 반복해서 재진입하면 웹 페이지가 오래 대기하거나 일부 도메인이 간헐적으로 실패할 수도 있습니다.
권장 데이터 경로
바이패스 라우터의 dnsmasq가 LAN의 53 포트를 수신하도록 한 뒤 요청을 mihomo의 127.0.0.1:1053으로 전달할 수 있습니다. 또는 방화벽을 통해 단말이 다른 DNS로 보내는 TCP/UDP 53 요청을 로컬로 리디렉션할 수도 있습니다. 이후 mihomo의 DNS 모듈이 도메인 규칙에 따라 직접 연결용 리졸버와 프록시용 리졸버 중 하나를 선택합니다.
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "time.*.com"
- "ntp.*.com"
default-nameserver:
- 223.5.5.5
- 1.1.1.1
nameserver:
- https://dns.alidns.com/dns-query
- https://1.1.1.1/dns-querydefault-nameserver에는 IP 주소를 사용하며, 주로 DoH 서버 자체의 도메인을 해석하는 데 사용합니다. 시작 단계에서 도메인이 먼저인지 DNS가 먼저인지에 대한 의존성 루프가 생기는 것을 막기 위해서입니다. nameserver는 실제 질의 진입점입니다. 더 복잡한 설정에서는 nameserver-policy로 특정 도메인에 서로 다른 리졸버를 지정할 수도 있지만, 먼저 기본 해석이 안정적으로 작동하는지 확인한 뒤 정책을 추가해야 합니다.
fake-ip와 redir-host의 선택
fake-ip은 예약 주소 풀에서 임시 주소를 반환하고 mihomo가 매핑을 통해 원래 도메인을 복원하므로 도메인 규칙을 직접 매칭하기 쉽습니다. 예시의 198.18.0.1/16은 벤치마크용 예약 대역으로 일반적으로 공인 IP와 충돌하지 않습니다. LAN 도메인, 프린터 검색, NTP와 실제 IP에 의존하는 일부 애플리케이션은 fake-ip-filter에 추가할 수 있습니다.
redir-host는 실제 해석 결과를 반환하므로 경로 호환성을 이해하기 쉽지만, 투명 프록시 단계에서 스니핑이나 IP 규칙에 더 많이 의존할 수 있습니다. LAN 장치 검색에 실패하더라도 DNS 가로채기를 전부 끄기보다는 먼저 대상 도메인을 확인하고 정확한 필터 항목을 추가하세요.
IPv6는 별도로 검증하기
IPv4만 가로채면서 단말에 IPv6 기본 라우팅을 계속 배포하면 IPv6를 지원하는 애플리케이션이 기존 정책을 우회할 수 있습니다. 해결 방법은 모든 AAAA 레코드를 단순히 삭제하는 것이 아니라 네트워크 역량에 따라 선택하는 것입니다. IPv6를 완전히 프록시하거나, 지정한 IPv6 대역만 직접 연결하거나, 아직 준비되지 않았다면 테스트 대역에 IPv6 기본 라우팅을 배포하지 않도록 합니다. 최소한 A와 AAAA 질의를 각각 수행하고 IPv4만 지원하는 사이트와 IPv6를 지원하는 사이트를 하나씩 테스트해야 합니다.
바이패스 라우터 적용 단계: 단일 장치 테스트부터 전체 네트워크 가로채기까지
바이패스 라우터는 단계적으로 적용하는 것이 좋습니다. 먼저 한 대의 컴퓨터만 바이패스 라우터를 사용하게 한 뒤 독립 장치 그룹으로 범위를 넓히면 전체 네트워크의 DHCP를 바로 변경하는 것보다 문제를 쉽게 찾을 수 있습니다. 다음 예시에서도 메인 라우터는 192.168.10.1, 바이패스 라우터는 192.168.10.2를 사용합니다.
- 바이패스 라우터 주소 고정: LAN 주소를
192.168.10.2/24로 설정하고 기본 게이트웨이를192.168.10.1로 지정해 메인 라우터의 DHCP 동적 할당 범위와 겹치지 않게 합니다. - IP 포워딩 활성화: Linux에서는
sysctl net.ipv4.ip_forward를 확인하며 결과는1이어야 합니다. IPv6 포워딩이 필요할 때는 해당 매개변수도 별도로 확인합니다. - 일반 포워딩 확인: 아직 Clash를 실행하지 않은 상태에서 테스트 컴퓨터의 게이트웨이를
192.168.10.2로 변경합니다. 이때 인터넷에 연결되지 않는다면 먼저 라우팅, NAT 또는 리턴 경로를 수정해야 하며 문제를 프록시 설정 탓으로 돌려서는 안 됩니다. - 명시적 프록시 확인: mihomo를 시작한 뒤 테스트 컴퓨터에서 HTTP 또는 SOCKS 프록시를
192.168.10.2:7890으로 수동 설정하고 노드, 구독과 규칙이 정상 작동하는지 확인합니다. - 투명 프록시 활성화: 먼저 TCP를 처리한 다음 UDP를 테스트합니다. 로그에서 인바운드 유형, 대상 주소, 적중 규칙과 최종 프록시 그룹을 확인하세요.
- DNS 가로채기 활성화: 테스트 컴퓨터의 DNS를
192.168.10.2로 변경하고nslookup또는dig로 응답 서버, 소요 시간과 A·AAAA 결과를 확인합니다. - 범위 확대: 안정적으로 작동하는 것을 확인한 뒤 메인 라우터 DHCP에서 지정한 단말의 게이트웨이와 DNS를 바이패스 라우터 주소로 배포하거나 VLAN을 통해 테스트 대역 하나만 가로챕니다.
테스트할 때는 구체적인 수치를 기록해야 합니다. LAN에서 바이패스 라우터까지의 유선 지연 시간은 일반적으로 1ms보다 짧아야 합니다. DNS 최초 질의가 계속 2초를 넘으면 DoH 연결 수립, 상위 라우팅과 루프를 확인하세요. 규칙을 전환한 뒤에는 20회의 해석 및 연결 테스트를 연속으로 수행해 간헐적인 타임아웃이 없는지 확인할 수 있습니다. 속도 테스트는 특정 시점의 처리량만 보여 줄 뿐 패킷 손실, 지연 시간과 지속 연결 테스트를 대신할 수 없습니다.
DHCP 배포 방식 두 가지
- 전체 네트워크에 배포: DHCP 옵션 3에서 기본 게이트웨이를
192.168.10.2로 지정하고 옵션 6에서 DNS를192.168.10.2로 지정합니다. 바이패스 라우터가 안정적으로 작동하는 네트워크에 적합합니다. - 장치별 배포: 테스트 컴퓨터, TV 또는 게임기에 정적 임대 설정을 만들고 해당 장치에만 바이패스 라우터의 게이트웨이와 DNS를 할당합니다. 사무용 장치와 관리 장치는 계속 메인 라우터를 사용하게 합니다.
일부 가정용 메인 라우터는 게이트웨이를 일괄 배포할 수만 있고 단말별 설정은 지원하지 않습니다. 이때는 테스트 장치를 수동으로 설정하거나 독립 게스트 네트워크를 나눌 수 있습니다. 하나의 문제를 해결하기 위해 이중 NAT, 브리지와 정책 라우팅을 동시에 적용하지 마세요. 경로 계층이 많아질수록 리턴 경로 불일치를 찾기 어려워집니다.
일반적인 장애와 점검 순서
단말은 바이패스 라우터에 접속되지만 인터넷에 접속되지 않음
먼저 mihomo와 투명 프록시 규칙을 중지하고 기본 포워딩만 확인합니다. 바이패스 라우터의 기본 경로가 메인 라우터를 가리키는지, IP 포워딩이 활성화되어 있는지, 메인 라우터가 단말 대역으로 돌아가는 방법을 알고 있는지 확인하세요. 단일 NIC 바이패스 라우터는 보통 같은 /24 대역에 있지만 독립 서브넷을 사용한다면 메인 라우터에 정적 라우팅을 추가하거나 바이패스 라우터에서 소스 NAT를 수행해야 합니다.
웹 페이지는 열리지만 게임 또는 음성 통화가 실패함
이는 보통 TCP 경로는 정상이나 UDP가 프록시에 들어가지 않거나 프록시 노드가 필요한 UDP를 지원하지 않는다는 뜻입니다. TProxy 또는 TUN이 활성화되어 있는지, UDP 규칙이 기록되었는지, 방화벽에 관련 모듈이 로드되었는지 확인하고 연결 로그에서 UDP 인바운드가 나타나는지 살펴보세요. QUIC는 UDP 443을 사용하므로 브라우저의 QUIC를 끄는 것은 원인 파악에만 사용할 수 있으며 올바른 UDP 설정을 대신할 수는 없습니다.
중국 본토 사이트 접속이 우회되어 느려지거나 LAN 장치에 접근할 수 없음
규칙 순서를 확인합니다. LAN 대역, 라우터 관리 주소와 사설 주소는 최종 프록시 규칙보다 앞에서 직접 연결되어야 합니다. 규칙은 위에서 아래로 매칭되며 마지막의 MATCH가 매칭되지 않은 모든 요청을 받습니다. LAN 도메인에 .lan 또는 .local을 사용한다면 fake-ip 필터와 로컬 DNS 전달도 함께 확인해야 합니다.
재부팅 후 잠시 인터넷이 끊김
방화벽 규칙이 먼저 로드되고 mihomo가 설정 파싱과 DNS 초기화를 아직 끝내지 못했을 수 있습니다. systemd 서비스는 network-online.target을 기다려야 하며, 방화벽 스크립트도 코어의 수신 포트를 사용할 수 있게 된 뒤 트래픽을 가로채야 합니다. 설정, Geo 데이터와 캐시가 재부팅 후 비워지는 임시 디렉터리가 아니라 영구 저장소에 있는지도 확인하세요.
CPU 사용률이 높거나 처리량이 크게 떨어짐
먼저 암호화 성능, 규칙 처리와 로그 기록을 구분합니다. 로그 수준은 info로 유지하고 장애를 조사할 때만 잠시 debug로 전환하세요. 정규식 규칙을 지나치게 많이 활성화했는지, 지속 연결 스니핑이나 중복 DNS 질의가 발생하는지 확인합니다. 기가비트 인터넷에서는 낮은 주파수의 듀얼코어 라우터가 먼저 단일 코어 병목에 도달할 수 있으며, 메모리 사용량이 정상이어도 포워딩 성능이 충분하다는 뜻은 아닙니다.
배포 결론: 먼저 라우팅을 안정화한 뒤 규칙 기능 확장
OpenWrt를 메인 라우터에 배포하면 진입점이 통합되어 하드웨어 성능이 충분하고 전체 네트워크 정책을 중앙에서 관리하려는 환경에 적합합니다. OpenWrt 바이패스 라우터는 LuCI와 플러그인 관리 기능을 유지하면서 장애가 발생했을 때 단말의 게이트웨이를 메인 라우터로 되돌릴 수 있습니다. 라즈베리 파이 또는 Debian 독립 실행 구성은 systemd, nftables와 로그를 더 명확하게 제어할 수 있어 Linux 네트워크 스택을 직접 관리하려는 사용자에게 적합합니다.
어떤 구성을 선택하든 안정적인 순서는 다음과 같습니다. 먼저 일반적인 3계층 포워딩을 확인하고, 7890 명시적 프록시를 검증한 다음 TCP 투명 프록시를 활성화합니다. 이후 UDP와 DNS를 보완하고 마지막으로 IPv6와 전체 네트워크 DHCP 배포를 처리합니다. Clash Meta 또는 mihomo는 데이터 경로의 한 구성 요소일 뿐이며, 실제 안정성은 게이트웨이, 리턴 경로, 방화벽과 DNS가 일관되게 유지되는지에 달려 있습니다.