IP camera stream 401 unauthorized in the client but not the designer

An IP camera that streams in the designer and then throws HTTP 401 - unauthorized in the client is one of the most common faults on SCADA and HMI camera projects, and it is almost never the camera hardware. The designer and the client are separate programs that reach the camera in different ways, and the difference comes down to credential delivery or the network interface the request leaves from. This guide walks the fault in the order you meet it: what a 401 proves, where the credentials belong, why a login popup appears on one side only, and how a two-NIC PC breaks the client while the designer keeps playing. Every step ends in a test you can run the same day.

Why does the stream work in the designer but return 401 in the client?

Because they are different processes making different requests: the designer's desktop runtime answers the camera's authentication challenge with a login popup you type into, while the client shows no popup, so its request goes out with no credentials and comes back as 401.

A 401 is an HTTP-level refusal. The client's packets reached the camera, the camera understood the request and rejected it, so reinstalling the platform or swapping Java versions changes nothing. A routing fault gives you a timeout; an authentication fault gives you 401. Keep those two failure classes separate from the first minute.

The designer working is often not the viewer working. Someone answered a popup raised by the desktop layer, the Windows and Java stack hosting the designer rather than the viewer component, and that answer satisfied the camera for that process only. The client never gets that help, so the same URL that plays in the designer returns 401 in the client. The Ignition IP Camera Viewer 401 unauthorized error fix walks the same signature on that platform.

Do the credentials belong in the URL or in the viewer's fields?

In the URL, with the viewer's Use Authentication property switched off: that combination works across the widest range of cameras, and you add credentials to the viewer's own fields only if the camera still challenges once the URL carries the account.

Two URL forms do the job. On an HTTP MJPEG endpoint the camera parses the account itself, as query parameters:

http://192.168.123.72:8072/videostream.cgi?user=user12&pwd=user12

For RTSP, the account rides in the authority part before the host, with TCP port 554 as the service default. Substitute your camera's address for camera-ip:

rtsp://user12:user1234@camera-ip:554/Streaming/Channels/1

Percent-encode reserved characters in the password or the URL parses wrong. Then work the matrix:

A 401 also shows up when the URL never pointed at a real stream endpoint, so rule that out alongside the credentials: see pointing an MJPEG viewer at the real stream. For the wider setup, the SCADA MJPEG stream configuration troubleshooting page walks the same checklist. And before fighting an rtsp:// URL your component cannot speak, read the IP Camera Viewer RTSP stream support limits.

Why does a login window pop up in the designer but not in the client?

The popup is not produced by the viewer: it is the desktop runtime hosting the designer answering the camera's HTTP authentication challenge, and the client has no window to open for the same challenge, so the request fails with 401.

Basic versus digest is the next split. A camera endpoint set to digest authentication rejects a viewer that only sends basic authentication, and it returns 401 even with the correct account and password. The credentials are right, the exchange is wrong. Two fixes: set the stream endpoint to basic authentication in the camera's web page, which is acceptable on a closed control subnet, or use the query-parameter URL form above, which the camera parses without issuing a challenge at all.

A popup on every designer launch is the tell that the viewer itself never sends credentials; it leaves the desktop layer to answer. That behavior does not move with platform or Java versions, so stop reinstalling and fix the delivery. It also explains why the same viewer runs one camera line at every other site and fights the next model: endpoints ship with different default authentication modes.

Is the client reaching the camera through the wrong network interface?

It can be, on the standard two-NIC integration PC with one interface for the internet and one for the control network with the camera, because the launch path decides which connection the client keeps, and the camera can then see the request arrive from an address it does not recognize.

The classic layout runs the gateway and the client on a PC with two NICs. One site logged HTTP 401 from the client launcher every time, while launching the client from the designer through Tools > Launch Project played the same stream, and pointing the launcher at the control-side address still failed. What differs is the connection the client holds to the gateway at startup, and with it the path the camera request takes.

Bring the client up over the control subnet, the one the camera lives on, so the platform traffic and the camera request share a path the camera recognizes. The same discipline governs industrial cameras on dual-NIC PCs: picking the right network interface for a GigE camera shows the checks. Remember that a 401 means something answered with HTTP, so on a routed plant network a proxy or a second answering host can issue the challenge; the browser test in the next section separates those cases.

How do you prove which path the request takes?

From the client PC itself, in this order: paste the exact stream URL into a browser on that machine, then read the routing table with route print and confirm the camera's subnet is on-link through the control interface. The browser reproduces the challenge; the route table names the interface.

Take the numbers from the layout above: control NIC 192.168.123.10 with mask 255.255.255.0, camera at 192.168.123.72 on TCP port 8072 for MJPEG and port 554 for RTSP, internet NIC 10.0.0.50 carrying the default gateway. In the route print output, the row for destination 192.168.123.0 mask 255.255.255.0 must list interface 192.168.123.10. If it does not, traffic to the camera leaves by the wrong NIC.

Read the browser result the same way. A login prompt followed by playback means the path is sound and the fault is credential delivery. A timeout means routing. A 401 with credentials already in the URL means the camera is rejecting the exchange itself, so go back to basic versus digest. Ping the camera address as a third check of bare reachability, with no authentication involved.

What is the fix, step by step?

Embed a view-only account in the stream URL, set the camera's HTTP endpoint to basic authentication, leave the viewer's own Use Authentication off, and bring the client up over the control subnet. Work in that order, with a browser test on the client PC between each change.

1. In the camera's web page, create a view-only account and set the stream endpoint to basic authentication.
2. Build the URL with that account: the query form http://192.168.123.72:8072/videostream.cgi?user=user12&pwd=user12 for HTTP MJPEG, or rtsp://user12:user1234@camera-ip:554/Streaming/Channels/1 for RTSP. Percent-encode reserved characters in the password.
3. Untick Use Authentication in the viewer and paste the URL. The designer should now play with no popup at all.
4. Open the same URL in a browser on the client PC. A login prompt followed by playback says the path is sound.
5. Launch the client over the control subnet: first from the designer via Tools > Launch Project, then from the launcher aimed at the control-side address.
6. If the camera still challenges, tick Use Authentication with the same account. Many running systems end up carrying credentials in both places.
7. Between attempts, restart the stream cleanly: close the client's socket rather than only the window, or the old connection holds the failed session. Restarting an MJPEG stream shows the sequence.
8. Record the working combination on the station sheet: URL form, authentication mode, account name, launch path.

When should the IP camera become a machine-vision camera?

When the image drives a decision, such as presence, measurement or code reading, replace the IP camera with a GigE Vision camera: frames arrive on demand with no HTTP authentication layer, and you choose the lens and the light for the job instead of accepting a surveillance picture.

A GigE Vision link carries no per-request HTTP authentication, so this fault class does not exist there. For a pure view-only screen the IP camera can stay: polling a snapshot URL on a timer sidesteps both the challenge and the held-open stream. Poll at 500 ms to 1 s intervals; a 640 × 480 JPEG snapshot is typically 30-80 KB per frame, so even 1 s polling is a fraction of a live stream's bandwidth. That page also shows how grabbing stills over a snapshot URL feeds image logic without a live stream. If the feed must stay RTSP, show it through a component built for it: displaying an RTSP stream in an HMI compares the options.

For a station that displays and inspects, start in GigE area scan cameras or the camera finder, filtered on the interface your control network already carries. A compact GigE camera with a global shutter and a C-mount, such as the MV-CU020-90GC, covers live view and inspection frames over a single link:

Keep that link on the control interface with a locking cable from the camera data cables range, built for cable-track movement:

To freeze inspection frames of moving parts, strobe the light from a digital controller instead of trusting exposure time alone:

The light controllers range drives constant-voltage and constant-current channels for that strobe, and the configurator below strings camera, lens, light and controller into one station:

What stops it coming back on the next machine?

Four standards per station: one view-only camera account, credentials carried in the URL, the endpoint locked to basic authentication on a closed subnet, and one written launch path over the control network for every client that will show the stream.

• Commission with the URL already carrying the view-only account, before any operator sees a popup.
• Record the camera's authentication mode next to its address on the commissioning sheet.
• On two-NIC PCs, write down which subnet carries the stream and which launch path uses it.
• Prefer snapshot polling on a timer for view-only screens: no held-open stream, no challenge on reconnect.
• Keep the camera on the control subnet or a VLAN with no route to the office network.

If the fault survives every step, send the working URL, the route print output and the camera's authentication mode through the contact page and the applications team will pick it apart with you.