Show an IP camera on a different network in your HMI

Your camera sits on the PLC network; the operators' HMIs sit on another. You point the HMI camera widget at the gateway's URL proxy — http://<gateway>:8088/main/system/urlproxy?url=http://<camera>/... — and instead of video the widget reports HTTP 407: Proxy Authentication Required. This guide walks the fault in the order you meet it: what the 407 is telling you, how to tell the proxy's demand from the camera's, the URL form that returns video, and the network layout that removes the proxy problem. It closes with the decision for each case, plus the cable and power details for the camera run.

What is HTTP 407 telling you?

HTTP 407 means the request reached the gateway's proxy and the proxy refused to forward it until you authenticate with the proxy itself — the camera was never contacted, so no camera password will change this response.

The status is the proxy's own demand, not the camera's refusal: the client must repeat the request with credentials the proxy accepts, and the response normally carries a Proxy-Authenticate header naming the scheme it wants, Basic or Digest.

In the set-up this guide tracks, the gateway is the only machine that can reach the camera. Its URL proxy — the path /main/system/urlproxy on port 8088 — fetches a URL on the camera side and re-serves it to HMI clients on the far network. That proxy layer has its own login, and a request without those credentials stops at the gateway. Nothing you change on the camera moves this answer until the proxy is satisfied.

Is the 407 coming from the camera or the gateway?

Test the two legs separately: request a URL that needs no login through the proxy, and request the camera's stream from the gateway host — a 407 on the no-login URL convicts the proxy, and a 401 from the camera convicts the camera.

1. From the gateway host, open the camera's MJPEG URL in a browser. Video means the gateway-to-camera leg is good. A 401 means the camera wants its own login, and the fix is the widget's credential properties.
2. Still from the gateway host, push a no-login page through the proxy: http://<gateway>:8088/main/system/urlproxy?url=http://<any-open-page-on-the-camera-LAN>/. A 407 here, on a page nobody protects, proves the proxy's login is the blocker.
3. From one client PC, repeat step 2. The same 407 means credentials; a dead page with no status means routing.

Step 2 is the decisive one: a plain file on the camera LAN, with no login anywhere, still answered 407 through the proxy in this set-up. That single result moves the fault off the camera and onto the gateway's auth layer.

How do you pass credentials through the urlproxy call?

Pass them as explicit query parameters — username and password appended after the camera URL — and the same request that returned 407 returns video; every embedded-credential variant of that call kept failing.

http://172.16.55.24:8088/main/system/urlproxy?url=http://10.0.0.72/mjpg/video.mjpg&username=viewer&password=hmi-view1

Here the gateway listens for clients on 172.16.55.24 and fetches from the camera at 10.0.0.72. Clients cannot route to the camera, which is why the proxy exists; the two parameters answer the proxy's challenge, and the camera serves the stream through it.

If the camera component has username and password properties of its own, prefer them — the credentials travel the same way but stay out of the visible URL. The MJPEG stream URL with username and password guide covers which forms each browser still accepts.

Why did the user:pass@ form stop working?

Because current browsers strip or block credentials embedded in the URL — the http://user:pass@host/ form worked in some older browsers, fails in current ones, and was never accepted by every client, so it is not a fix you can ship to an HMI.

RFC 3986, the standard that defines URL syntax, marks the user:password form deprecated, and browser makers removed it from address bars and embedded requests one after another. A workaround that depends on the client's version passes your bench test and dies on the first updated operator PC. Camera credentials belong in the widget's properties or the proxy's parameters, never in the address anyone can read.

Which network should the camera sit on?

Keep the camera on the machine LAN beside the PLC, give the gateway one interface on that LAN, and let every client reach the camera through the gateway — one hop, and no camera port exposed to the office network.

The addresses in this set-up decide it:

• Camera: 10.0.0.72, mask 255.255.255.0
• Gateway, machine-LAN interface: 10.0.0.73, same mask — the gateway reaches the camera directly, no router involved.
• Gateway, client-LAN interface: 172.16.55.24 — clients on 172.16.55.x reach the gateway directly and cannot route to 10.0.0.0/24, which is exactly why they need the proxy.

Fix the camera's address statically — camera static IP on the same subnet — so the proxy URL never goes stale. Give each gateway interface its own subnet: picking the right network interface applies to any camera, and two adapters on one subnet hang acquisition. When a router rather than a second interface separates the camera, work through IP camera behind an industrial router: NAT and RTSP fixes before you open a single port.

How much bandwidth does one proxied stream save?

Roughly the whole camera-side load: a 1280×720 MJPEG stream at 10 fps with 60 kB frames is 4.8 Mbit/s, so four clients pulling directly cost the camera 19.2 Mbit/s and four connections, while the proxy holds it to one stream and re-serves the four.

Example inputs, not a camera spec: 60 kB per JPEG frame is a fair mid-range figure for a 1280×720 indoor scene; motion and gain push frames toward 100 kB and the result with them.

Four clients, four direct streams: 4 × 4.8 = 19.2 Mbit/s through the camera's own port, plus four of its MJPEG connections. Through the gateway: the camera serves one 4.8 Mbit/s stream, and the client LAN carries the same 19.2 Mbit/s where the capacity already sits. Cameras cap simultaneous MJPEG connections — proxy one stream for all clients exists for exactly this pattern.

Snapshot, MJPEG or RTSP: which URL goes in the widget?

MJPEG through the proxy for live operator video, a snapshot JPEG URL for anything under one frame per second, and RTSP only when the gateway side re-streams it, because a browser HMI cannot play RTSP on its own.

The camera's own web UI is the catalogue: the address its live page loads is usually the MJPEG path, commonly ending in .mjpg — /mjpg/video.mjpg on many models — with a single-frame JPEG path listed beside it. Both travel through the proxy the same way: wrap the camera path in urlproxy?url= and append the parameters. For what each URL type renders, and why a widget shows grey, read HMI camera widget grey: MJPEG vs RTSP and snapshot JPEG URLs and showing a machine-vision camera image in a web browser HMI.

What should you check before you commit the design?

Walk this list in order: one stream per camera, credentials in properties or parameters but never in a shared URL, two gateway interfaces on two different subnets, camera cable and power sized for the run, and a status-code test from one client PC before sign-off.

• Camera side: one MJPEG connection per camera, opened by the gateway.
• Credentials: a viewer-only camera account, carried by the proxy parameters; no user:pass@ anywhere in the project.
• Subnets: machine LAN and client LAN differ; one subnet per interface.
• Widget: MJPEG URL for live view, snapshot JPEG for slow updates, credentials in the component's properties.
• Client test: the proxy URL answers with video from a client PC, not only from the gateway host.

Route the camera to the machine switch on one continuous channel, and keep any single Ethernet run under 100 m. The LS-CBL-0117 is an RJ45 camera data cable with a locking stud, 15 m long. The LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks, built for drag-chain use. Filter camera data cables by length for the run you measured.

If the camera takes PoE, feed the injector or powered switch from a 48 V rail. The LRS-75-48 supply is rated 48 V at 76.8 W. Four 802.3af ports at the standard's full 15.4 W each draw 4 × 15.4 = 61.6 W, leaving 15.2 W of headroom for the injector's own losses.

Other rails sit in power supplies; the accessories finder lists cables and supplies together, and the cabling step of the configurator bundles them into one build.

So which fix applies to your case?

Match your test result to the case and apply the one fix: 401 goes to the widget's credential properties, 407 goes to the urlproxy parameters, no route goes to the second interface, and viewer count goes to the proxied stream.

• Your test returned 401 from the camera: put the camera's viewer account in the widget's username and password properties. The proxy is innocent.
• Your test returned 407 on a no-login URL: add username and password parameters to the urlproxy call. The camera is innocent.
• The page will not even open: the client and the camera share no route — give the gateway an interface on the machine LAN and proxy from there.
• Many operators, one camera: the gateway opens the single stream and re-serves it; the camera never sees a second connection.

When the widget shows video, write the working URL, the account name and both interface addresses on the cabinet documentation — the next person to debug this needs all three. Bring the layout, the camera model and one failing status code to the contact page and we will size the camera, cabling and power with you.