IP camera stream works on the server but not on clients

You put an IP camera feed on an HMI screen, and the picture is perfect in the seat where you built it: the server. Every client that opens the same window waits, then reports a connection timeout. Almost always, the camera and the platform are both fine and the fault is routing: HMI clients fetch the camera's stream from their own machines, not through the server, so the picture appears only where a route to the camera exists. This guide gives you the one-minute client-side test, the reason a 169.254.x.x camera address can never reach clients on another subnet, the port-forward fix worked through with real numbers, and the cases where routing is not the problem at all.

The symptom: works on the server, timed out on the client

A stream URL in an HMI design is only a string. Whoever opens the window is the one who connects: the server succeeded because it can route to the camera, which is why you saw video while designing. A client on another subnet opens a TCP session from its own address, and when no route to the camera exists the attempt gets no answer at all. The client waits out its connect timer and reports a timeout.

That wording carries the diagnosis. A timeout means the packets vanished: a routing gap, or a firewall dropping them without a reply. A refused connection means the packets arrived and something answered no — a closed port, the wrong port, or rejected credentials. Routing and firewall work fixes the first; URL and credential work fixes the second.

The same server-versus-client split catches HMI scripts that run on the server and fail on clients, so the pattern is worth knowing beyond video. In every case the rule is identical: test from the client, never only from the server.

The one-minute test: open the camera's page from a client

1. Sit at a failing client and open the camera's built-in web page in a browser, at the same address the stream URL uses, port included. The page and the stream share one listener, so a page that loads proves address, port and routing end to end.
2. If the page loads and the HMI window still shows nothing, routing is solved: the widget holds the wrong URL or lacks credentials. Work through MJPEG viewer shows no video: point the URL at the real stream, then an IP camera stream returning 401 in the client but not in the designer.
3. If the page times out, repeat the test on the server. Server yes, client no: that client has no route to the camera, and the next two sections apply.
4. After you create a routable address or a forwarded port, rerun this test from every client subnet with the new address before you touch the HMI design.

Why a 169.254 address stops at the server's link

The address 169.254.169.10 sits inside 169.254.0.0/16, the IPv4 link-local block. Link-local addresses are self-configured, valid on one physical link, and routers do not forward them between subnets. The only machines that can open this camera are the ones sharing its segment, typically the server cabled next to it. Clients on the plant LAN never share that link, so their sessions die as timeouts.

That is the whole failure. The server shows video because it sits on the camera's link, and every client elsewhere times out because nothing will route 169.254.x.x to them. No camera setting fixes it, and none is needed: the camera was never broken.

Worked example: forward a routable port to a camera at 169.254.169.10

Inputs, from a working field case — substitute your own where they differ:

• Camera address: 169.254.169.10, link-local, taken from the URL that works on the server.
• Camera port: TCP 80, because the working URL carries no port number, so it uses the standard web port.
• Forwarded port: TCP 9000, the port chosen in the field case.
• Client address: 192.168.1.50 with mask 255.255.255.0, a typical plant client, illustrative.

The rule in words: a client can open the camera only if the camera's address lies inside the client's own subnet, or a router carries the session to it. No router will carry 169.254.0.0/16 between links, so a device already on the camera's link must translate a routable address to the camera.

The arithmetic:

• 192.168.1.50 masked with 255.255.255.0 gives network 192.168.1.0, so the client's own subnet spans 192.168.1.1 through 192.168.1.254.
• 169.254.169.10 is outside that span, so the client passes the session to its default gateway instead of the camera.
• The gateway does not forward 169.254.0.0/16 onto another link, so the attempt gets no answer and matures into the reported timeout.
• On the router or firewall that shares the camera's link, forward TCP 9000 on its routable plant address to 169.254.169.10 on TCP 80.

The outcome: a client enters routable-plant-address:9000 in a browser and the camera page loads from every subnet that can route to that address; the HMI stream URL becomes the same address and port. The field case behind these numbers went live exactly this way, port 9000 forwarded at the firewall and clients pointed at the routable address, with video on the server and the clients alike.

The decision: keep the forward while the camera must stay link-local. As soon as you control the camera's addressing, give it a static address on the clients' subnet and delete the rule; that is the durable layout, and one forwarded port per camera is one more rule to carry through every future network change. Keep the forwarded port on the internal network.

The three fixes compared

The relay exists for exactly this failure: newer gateway software can fetch the camera server-side and serve the clients itself, so the camera needs to be reachable from one machine instead of all of them, and a small RTSP-to-MJPEG relay beside it does the same job. Streaming an IP camera to vision clients covers the client-side questions that follow. If you are building the screen rather than debugging it, start from showing a camera live stream in an HMI web viewer widget or embedding an IP camera stream in an HMI or SCADA window.

When the usual answer is wrong

• The camera page loads on the client but the HMI window stays dark. Routing is proven good, so stop chasing it: the widget holds the wrong URL or lacks credentials. An MJPEG stream URL with username and password: make it play is the next step.
• Ping answers from the client but the page never loads. ICMP and TCP are different rules to a firewall, and a duplicate address can answer a ping without being your camera. Read camera IP conflict: ping works but the web page is wrong.
• It works on the plant and fails from outside. Do not widen the firewall; route the outside in. Adding a remote subnet route for a smart camera over VPN is the pattern.
• The client showed a picture at design time and never again. That is design-time preview against run-time stream, not routing: see vision locate works in teach but fails at run time.

Every direct client is another stream session

A 640 x 480 frame is 640 x 480 = 307,200 pixels, about 300 kB in 8-bit monochrome before compression. Every client that connects directly opens its own session and receives its own copy, so the camera's uplink carries the stream once per client. Two or three direct clients is a normal load; past that, relay one session through the gateway or refresh a snapshot instead of streaming. The trade-offs sit in why an MJPEG stream slows HMI pages: stream vs snapshot URL.

Parts for a station every client can reach

The durable layout homes the camera or vision sensor on the switch its clients already use, with a static address in that subnet. Ethernet reach beats routing tricks: a longer run to the clients' switch removes the forwarding rule entirely, and these are the cables for that run:

Smart cameras and code readers carry the same rule: their configuration pages and image streams are exactly as reachable as their addresses. Three Ethernet-interface examples suit that layout:

The MV-SC3050XC-16M-ATN-H is a 5 MP Fast Ethernet vision sensor, the LS-SMC-0063 is a 1.6 MP GigE smart camera, and the LS-CRD-0028 is a 5 MP Fast Ethernet code reader. Give any of them a static address on the clients' subnet and the reachability test above applies unchanged.

Checklist: prove it from every client

• The camera's web page opens from every client subnet, checked in a browser on a client, never only on the server.
• The client design references the routable address or the gateway relay URL, never 169.254.x.x and never a name only the server resolves.
• The firewall passes the camera's TCP port from the client VLANs: 80, or the forwarded 9000.
• Remote viewers reach the plant through a VPN, not an open internet port.
• The direct client count stays at two or three; beyond that the design uses the relay or snapshots.
• After any camera swap or address change, the client-side page test runs again before sign-off.

To pick the parts, browse the camera and code reader finder for Ethernet-interface cameras and readers, choose cables and accessories for the run to the clients' switch, or start a full station in the configurator. If the network side is tangled, raise it with our applications support. More articles on this class of failure sit on the systems topic page.