Proxmox LXC Container Has No Internet: Diagnose Bridge, Gateway and Firewall

A container that does not stay running never reaches network-path diagnosis.[1]

• Yes, it runs but has no external path → Does the container have a live address?
• No, it does not stay running → This is a container lifecycle problem, not a network path
• I have not checked → Check the container running state

Record whether the container starts and stays running before any network observation.[1]

Only a running container continues on this page.[1]

• It runs but has no external path → Does the container have a live address?
• It does not stay running → This is a container lifecycle problem, not a network path

A container that does not stay running needs lifecycle diagnosis (template, storage, resources, task log), not bridge or gateway checks. Preserve the state and log output and use the matching workflow.[1]

Compare container network settings with live address state. A present address continues to reachability checks; it never by itself declares the network healthy.[1][5]

• Yes, an address is present → Can the container reach the LAN or host side?
• No, no address is present → Resolve address assignment before path checks
• I have not checked → Compare configured and live addressing

Record the configured container network settings and the live address state side by side.[1][5]

A configured address that is absent at runtime is an assignment gap, not an upstream outage.[1]

• An address is present → Can the container reach the LAN or host side?
• No address is present → Resolve address assignment before path checks

Without a live container address, gateway and external tests cannot localize the fault. Investigate container network settings and address assignment first; do not change bridge, firewall, or upstream configuration yet.[1]

Test LAN-side reachability before external destinations. LAN success narrows the fault toward gateway, firewall, or upstream layers.[2]

• Yes, LAN responds → Does the intended gateway respond?
• No, nothing local responds → Stay in the container and bridge layers
• I have not tested it → Run the LAN reachability check

Test a LAN-side destination from the container context and record which side was actually tested.[2]

Total local failure stays with addressing, bridge attachment, or host path.[2]

• LAN responds → Does the intended gateway respond?
• Nothing local responds → Stay in the container and bridge layers

Check container addressing, bridge attachment, and host bridge state before gateway, firewall, or upstream changes. An untested external destination cannot explain a local failure.[2][6]

Confirm the gateway this container design intends. A responding gateway makes a fully broken local path less likely but never proves firewall or upstream behavior.[2]

• Yes, the gateway responds → Which network design does this container intend?
• No, the gateway does not respond → Distinguish design, bridge, and host path
• I have not tested it → Test the intended gateway

Test the intended gateway from the container context using the design's expected interface.[2]

An unresponsive gateway keeps the investigation at design, bridge, or host-path layers.[2]

• The gateway responds → Which network design does this container intend?
• The gateway does not respond → Distinguish design, bridge, and host path

Confirm the intended gateway for this bridged, routed, or masquerading design, then compare bridge attachment and host path state. Do not change firewall or upstream configuration before the gateway layer is classified.[2]

Bridged, routed, and masquerading are different designs with different bridge expectations. The official routed and masquerading examples intentionally use a bridge with no physical member, so an absent member alone is never a fault there. Establish the intended design before any bridge verdict.[2]

• Bridged, with an expected physical member → For this bridged design, is the container on the expected path?
• Routed → Routed design needs routing evidence, not a bridge member
• Masquerading (NAT) → Masquerading design needs forwarding evidence, not a bridge member
• I do not know yet → Determine the intended design before any change

For a routed design, a bridge with no physical member may be intentional and does not by itself establish a bridge failure. Continue into routing and forwarding design checks supported by the official documentation, and do not apply the bridged attachment fix. Record the documented design before any change.[2]

For a masquerading design, a private bridge with no physical member may be intentional and does not by itself establish a bridge failure. Host forwarding and NAT belong to the documented design only where it requires them; do not invent route or NAT parameters and do not apply the bridged attachment fix. Record the documented design before any change.[2]

Without a confirmed intended design, no bridge verdict and no network change is possible. Record the current container configuration and determine whether the design is bridged, routed, or masquerading first; do not guess whether a physical member should exist.[2]

This branch applies only because the intended design is bridged with an expected physical member. Compare the configured bridge against live bridge port state. A configured bridge entry never proves the datapath forwards.[2][6]

• Yes, attached to the expected bridge → What fails with addressing, gateway, and bridge confirmed?
• No, wrong bridge or missing member → Bridged discrepancy confirmed — use the bounded procedure
• I have not checked → Compare configured bridge with live ports

Record the configured container bridge and the live bridge ports and physical membership.[2][6]

A present configuration entry is not a working datapath.[2]

• Attached to the expected bridge → What fails with addressing, gateway, and bridge confirmed?
• Wrong bridge or missing member → Bridged discrepancy confirmed — use the bounded procedure

For this confirmed bridged design, the comparison shows the container is not on the expected bridge path with its expected member. Preserve the current configuration exactly as recorded. Apply only the bounded bridged network-change procedure in Next actions, and only with console or independent recovery access; host-wide bridge changes are out of scope here. Routed and masquerading designs never reach this outcome for an absent member alone.[2]

With container, gateway, and bridge layers confirmed, separate firewall scope from upstream behavior. A responding gateway never proves firewall or upstream correctness.[4][2]

• Names fail or policy denies the path → Inspect firewall scope and resolution separately
• Comparable external IPs fail with no policy denial found → Continue at the upstream and design layer
• I cannot tell yet → Record each layer before a change

Inspect Proxmox VE firewall state at container, node, and datacenter scope, and separate a failing hostname from a failing comparable IP connection. Do not disable the firewall as a test; request a scoped correction with the exact scope, rule, and direction.[4][1]

With local path, gateway, bridge, and firewall scope confirmed, continue at outbound and upstream design: the intended bridged, routed, or masquerading model, the upstream router, and NAT where the design requires it. Do not convert designs as a probe.[2]

Record container state, addressing, LAN result, gateway result, bridge comparison, and firewall scope. An unclassified layer is unknown, not a confirmed cause, and no change should precede classification.[2]